We upgraded to 2018.4.9 this morning and we are now having issues with permissions when editing variables.

I can reproduce the issue by creating a User Role that only has VariableEdit and VariableEditUnscoped permissions. I assign a Team to this role and as soon as I try and restrict it by Project or Environment I get the following error on screen when editing a variable:

This action requires permission to edit variables belonging to a project. 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: …"

I have tried adding all Projects and all Environments individually but still get the same error. It’s only when I leave the Projects and Environments blank does it work.

This has meant I have had to give our support team a wider range of permissions than they need so a speedy resolution would be appreciated!

I’m sorry to hear you are experiencing this issue, I’m conscious that your current workaround is not ideal so I’m hoping we can resolve this ASAP.

I’ve not been able to replicate this same issue in my own instance at this stage, unfortunately.

If possible, can you please provide an Export of one of the associated Users permissions (prior to relaxing the restrictions?), you can produce this information via Configuration > Test Permissions in the Octopus portal. You’ll need to specify the User here and an option for Export will appear in the top right.

It would also be valuable if you could include a screenshot of the associated error itself and the Team settings found via Configuration > Teams related to this user.

Finally, can I also please confirm which version of Octopus you originally upgraded from?

I look forward to hearing back from you, your patience and understanding are greatly appreciated

As previously mentioned, I had a chat with the team regarding this in our catch-up.

I’m going to make a Github issue for this (which I’ll link here ASAP) to address this, as it does seem to be related to the change in 2018.4.7 as outlined above.

In the interim of a permanent resolution, as a workaround you can either;

Rollback to 2018.4.6 (ensuring a database backup is taken prior), please be aware, however, that you will then be susceptible to the bug I outlined previously, please have a read of this issue for more information.

or

Stay with your current workaround by not providing scoping to Projects/Environments, (though I’m conscious this is not ideal as you’ve mentioned.

I don’t have ETA on a permanent resolution at this stage, however, I have flagged this as a concern with the Team and have left a personal note to update this case when this is resolved, additionally the associated Github issue will be the best place to keep up-to-date on the progress.

I’ll include the link here shortly.

Please let me know if you require any further assistance or clarification .

Hopefully, we can resolve this issue promptly. I’m sorry for the inconvenience caused as a result.

I can see that the GitHub issue has been closed as this is “by design”. I’ve added a comment as to why this design doesn’t make any sense but I don’t know if the dev will see this as the item is closed.

Can you make sure the dialogue around this issue stays open until an acceptable way forward is reached?

I had a chat with the Team about this in our catch up and highlighted this again as a concern.

At a high level, how I would personally imagine this to work is that provided the logged-in user’s team is scoped to ALL the current Projects connected to the Tenant then editing the Common Variables is acceptable as any changes here would otherwise affect unscoped Projects.

In scenarios where new Projects are connected to the Tenant, then it should prompt an error to indicate that a Project exists that is scoped to your Team to be clear where the problem resides. (Though that’s just my own thoughts on the matter)

I’ll update you again shortly as I believe we’re still in the process of working out how we’re going to handle this.

I will get back to you ASAP, your patience and understanding in this matter are greatly appreciated