We are running version 3.14.1, and when a user tries to cancel a deployment task they have created, we get this error in the diagnostic log:
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: DeploymentCreate (username@domain.com.au requesting https://octopus.domain.com.au/api/tasks/ServerTasks-2011/cancel f542909026904410b4d14ae0b10b7929)
Users are all using the Project Deployer role, which has DeploymentCreate and TaskCancel rights, so I don’t understand why they can’t perform this action.
Thanks, Simon.
Hi Simon,
Thanks for getting in touch! We have tested with version 3.14.1 and have failed to replicate the issue that you have reported. At this point I suspect either a precedence or permissions restriction issue. To get a better indication of what is occurring are you able to test the permissions against one of the affected users, then export and attach the output for review? I’ve attached a screenshot showing where the test permissions section is currently located, if you have any issues please let me know.
Look forward to hearing from you!
Regards
Alex
Hi Alex - I’ve attached the permissions for one of the affected users. The task he was trying to cancel is for the TEST environment for the tenant British Council, for which he does seem to have the TaskCancel permission.
Perhaps it is because he is a member of another team which has rights for the UAT environment for the same tenant, but this team does not have permission for the TEST environment???
Thanks, Simon.
Permissions_export_2017_07_05__01_45_59_UTC.csv (11 KB)
Hi Simon,
That sounds very much like you have found the issue as Octopus permissions are handled on an exclusion basis rather than an inclusion basis. In this case the exclusion of permissions from the team that doesn’t have access in this environment is over-riding the permissions of the team that does have the required access,
To confirm that this is what is occurring would it be possible to temporarily remove the user from the team that doesn’t have the required permissions in this environment? Once this has been confirmed you will need to modify your permissions structure to account for users that have permissions in both environments.
Any further questions please get in touch
Regards
Alex
Hmm, thanks for the information, Alex. If that is the case it will make assigning these permissions quite difficult, if not impossible, since we have a requirement to limit people’s deployment rights based on both Tenant and Environment. I will confirm first that this is indeed the case, and then see if I can come up with a way to resolve it, but I would really have thought that if you had been given explicit permission to deploy to TEST for TenantA in one team that permission to deploy to UAT for TenantB in another team would not affect this, they should be totally independent. It seems that the tenants specified in the team permissions are not being looked at when evaluating whether a user has the correct permissions to perform the action they are attempting…
So if I’m understanding this correctly, then a user can’t really be a member of multiple teams, doesn’t that defeat the purpose of having a team-based permission structure? The team permission structure is based on a combination of environments and tenants, so is explicitly defined and should not be undermined by the permissions of another team I would have thought.
And also, if the teams are overriding each other so that they cannot cancel a task, how come they are able to create the deployment in the first place, when the DeploymentCreate permissions are the same as the TaskCancel ones? Shouldn’t the same thing apply there so they wouldn’t be able to create the deployments? I think there’s something amiss here still…
Cheers, Simon.
Hi Simon,
Thanks for the information! I’ve passed this on to a developer who is investigating how your permissions structure is implemented and will get back to you as soon as we have more information for you.
Regards
Alex
Thanks Alex, I’m keen to hear his thoughts.
Cheers, Simon.
Hi Guys - In an effort to work around this issue, I have attempted to restructure our team permissions. Using one person, I have limited their membership to a single team, with certain environments. He deployed to an environment, then attempted to cancel it, and received this message:
This action requires permission to deploy releases to target environments. 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: Team City Auto Deployment and Octopus Administrators.```
I have attached his permissions, is it the fact that he is also a member of the Everyone team that is causing this? I think it's something more sinister, as I mentioned previously if he can create the task, he should be able to cancel the task, or not create the task in the first place. The error message states that he is missing the **DeploymentCreate** permission, yet he was able to create the deployment???
Cheers, Simon.
<a class="attachment" href="//octopus-help.s3-us-west-2.amazonaws.com/original/1X/1b0a63ba34b88a97bef71fc8fbb16482dd2e97e1.csv">Permissions_export_2017_07_11__03_48_14_UTC.csv</a> (3 KB)
Hi Simon,
I apologise for the lack of updates and responses on this one. Also, I want to pass on some thanks for following through with some extra information which was very useful for our investigation. We have identified two bugs related to the issue you identified and have raised two GitHub issues; Cancelling a task should only require the TaskCancel permission #3656 and Cancelling a task is not appyling tenant scope correctly #3657.
If you subscribe to both of those issues you will receive notification when the fixes are pushed into a production release.
Again, apologies for the time that this has taken, please let us know if there is anything else that we can assist with,
Regards
Alex
Thanks Alex, I look forward to seeing those issues resolved. No apologies needed, I know there are a lot of support issues to deal with!
Cheers, Simon.
Hi Simon,
Thanks for understanding, I’m looking forward to having these issues resolved as well!
Happy deploying,
Regards
Alex
Hi Alex - I can confirm that the 3.15.3 build has now fixed this issue, and our users can now cancel their own tasks. Thanks for the quick action!
Cheers, Simon.
