We’ve encountered a problem with role permissions for viewing release details for specific environments.
The issue seems to happen when users are assigned role that restricts their access to projects. Roles in question have access to 4 projects and all environments, however users assigned to this role are not able to view release details in two of 6 environments (we have Integration, Test, UAT, Pre-Live, Live, DR). The error message seems to indicate that the Task View permission has not been added to the role (it has) and only Octopus Administrators group have access to it. The only workaround we found is to remove all project groups from the team group which gives users access to all projects. I’ve attached the screenshot of the settings of the Team group and error message that shows up when viewing release details. Any feedback would be greatly appreciated.
The set up of roles and team groups was migrated from 2.6 to 3.010. The accounts have been added via AD security group and the users can see and view projects then have been assigned to just not releases on Live and DR environments
Can you setup a team with just the Task View permissions, and not scoped to any environments or projects and assign that team to the a user that is part of the DBRole and see if the permission is correctly applied?
I’ve added the DB role user to the new team/role with Task View permissions only - not scoped to any environment/project (except for the scopes in the DB Team).
Unfortunately that has not resolved the issue and the error message remains the same:
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: TaskView
This action requires permission to view summary-level information associated with a task. At least one of your teams has this permission in a limited scope, but this doesn’t cover the project or environment in question. Teams that have enough permission include: Octopus Administrators.
Just to clarify, the users has been added to both teams - DB and Task View. DB Team has scoped environments and projects, Task View team has not (empty fields). The permissions in the Task View Role assigned to Task View Team include “Task View” and “Task View Log”.
This is very curious as I have setup a team (same roles and scoped to projects/environments) locally and tested it out and it gives me access to the Task Log.
On the Teams tab under Configuration can you go to the Test Permissions page (top right corner) and select one of the users that is part of the DB team and see what permissions Octopus has determined they have.
The permissions are correctly displaying in the Test Permissions page. I can see both TasView and TaskVIew log being inherited from the roles. I was hopeing that it might have been the issue with imported accounts from the 2.6 version but those local accounts are non functional and the only ones created are added through AD security groups.
I’m really not sure what is going wrong here and as I don’t have your environment in front of me I can’t really replicate your scenario.
So, to try to get to the bottom of this issue, we can schedule a support call so we can do a screensharing session to try and get to the bottom of this issue.
Thanks for your time earlier today to go through the issues you guys are experiencing with permissions.
As a start to try and understand what is going on here, could you please run the following SQL queries on your Octopus server, this should show us what the difference is between pre-upgrade and post-upgrade. (Should hopefully tell us if something’s been missed in the migration). The fields that are of interest are ProjectId and EnvironmentId.
SELECT *
FROM ServerTask
WHERE Id = '<idoftaskthatworks>'
SELECT *
FROM ServerTask
WHERE Id = '<idoftaskthatdoesntwork>'
I’ll keep investigating the migrator and the way we apply permissions in the morning, but hopefully the queries above will narrow the search down for us
Just a quick update, after further investigations we have found that when we migrating server tasks, the Project Ids that the server task was scoped to were not being remapped. We believe this will be the cause of your issues with permissions and viewing tasks / task logs.
Once I get the additional data I requested above, we should be able to confirm this is the case.
Sorry about the late response I was away from the office yesterday.
I’ve attached the output for the tasks from the same environment and the same project (different releases)
Thanks for sending through that data, it does confirm what I mentioned earlier that the migrator didn’t remap the project Ids for server tasks.
We have fixed this in the latest build, so if you wanted to you can install the latest build and then migrate your 2.6 backup again (you’d have to select to overwrite matching records that are found in the SQL database, i.e. the records you’ve already migrated) and it should fix up these server tasks and users should be able to see the task logs again.
Let me just confirm with the team about the overwriting part (I wouldn’t want something to go wrong for you), I’ll get back to you tomorrow.
So sorry for the delay in getting back to you, we have come up with a solution that should fix the issue with permissions on server task logs.
The solution is to:
Delete all server tasks that happened prior to your 3.0 upgrade (based on the Queue Time column)
Install the latest version of Octopus Server so you have the fixes for the migrator
Then re-import your 2.6 backup which will then re-import the server tasks that were created in 2.6 and the project Id’s will be correctly remapped.
I’ve tested this locally and it has fixed the issue with the incorrectly mapped project id’s for server tasks BUT just to be overly cautious, take a backup of your SQL database before running through the above steps just in case something should go wrong.
If you have any questions or concerns, please do not hesitate to get back to me.
We have the exact same problem, where user assigned to just some projects lack Task View permissions when entering some projects.
The procedure described above; won’t it overwrite any changes that has been done since the initial migration? Is it safe to do even though we have worked on 3.x for some weeks?
The steps given will only remove server tasks that are from 2.6, when you then run the importer again with your 2.6 backup, it will not overwrite or remove any changes that have been done since the migration.
If you still have concerns that running the importer again will undo anything that has been done post-migration you can always take a backup of your 3.0 database, restore it to another server and setup an Octopus instance to use that database and run the importer on that instance (instead of your production instance) and you should be able to confirm that nothing that you don’t want changed will be changed.
After having another look at the migrator, I was wrong in my previous statement that we will not overwrite anything that existed in 2.6 and has been modified in 3.0, if an object that existed in 2.6 has (since the initial migration) been modified, it will be overwritten with the object from 2.6.
Anything that has been created in 3.0 (i.e. new projects/releases/users/teams etc) will not be removed/overwritten.
Sorry for my previous, incorrect statements about how we treat existing items when importing a 2.6 backup.
Hi, I am having this issue as well. It seems like a very heavy fix to have to go back to 2.6 and then re-import back to 3.0. I have hundreds of users and projects and don’t want to take this risk. Is there another fix for this problem? Thanks
Sorry for the delay in getting back to you, unfortunately the only other way to I can think of to fix this is to run a SQL script to update the incorrect project IDs in the server task table. This way is much more complicated as you have to manually map the 2.6 project IDs to the new 3.x project ids
