Task View problem in specific environments

Hello

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

Thanks,
Andrzej

Hi Andrzej,

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?

Thank you and kind regards,
Henrik

Hello

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.

A.

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”.

Hi Andrzej,

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.

Thanks,
Henrik

Hi Henrik

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.

Hi Andrzej,

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. To schedule a call just go to this site https://calendly.com/octopusdeploy/supportcall), select your timezone and then pick a time that is suitable for you and we will be notified of the scheduled support call.

I look forward to hearing from you soon again.

Warm regards,
Henrik

Hi Andrzej,

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 :slight_smile:

I look forward to hearing from you soon.

Thank you and warm regards,
Henrik

Hi Henrik

I’ve attached the output from the query in excel file.
Let me know if you need anything else.

Thanks,
Andrzej

Book1.xlsx (8 KB)

Hi Andrzej,

Thanks for sending through those, but I should have asked you could send me the server tasks from the same project and environment.

Sorry about that, and warm regards,
Henrik

Hi Andrzej,

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.

Thank you and warm regards,
Henrik

Hi Henrik

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,
Andrzej

Book1.xlsx (8 KB)

Hi Andrzej,

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.

Talk to you soon again.

Thank you and warm regards,
Henrik

Hi Andrzej,

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:

  1. Delete all server tasks that happened prior to your 3.0 upgrade (based on the Queue Time column)
  2. Install the latest version of Octopus Server so you have the fixes for the migrator
  3. 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.

Thank you and warm regards,
Henrik

Hi,

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?

Regards,
Espen

Hi Espen,

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.

Hope that helps,
Henrik

Espen,

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.

Warm regards,
Henrik

?
I’m currently out of the office on anual leave until 28th of September with limited access to emails

Please can you direct your emails to websupport@wintechnologies.netmailto:websupport@wintechnologies.net

Kind regards,

Andrzej

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

Matt

Hi Matt,

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

Thank you and kind regards,
Henrik