I’m using Octopus 3.12.4 and have noticed that some users couldn’t add variables to a project, yet they belonged to a team which had the Project Contributor role.
The error they were getting was:
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: VariableEdit
We only recently upgraded to 3.12.4 and I think (but can’t confirm) that this issue was introduced after the upgrade.
Upon investigating I have found that the cause of the problem was that the team was restricted to certain environments, when I removed the environments so that it was ‘any environment’ it worked again.
Thanks for getting in touch! When exactly are your users getting this error? Only when they try adding variables scoped to environments in which their team is not scoped to? Or are they also getting this error when scoping variables only to environments they are scoped to?
I tested this with a user who is in a team with the same role, and the behavior I’m seeing is what is expected. My user can add variables scoped only to an environment in which their team is scoped to - they just can’t add unscoped variables (or variables scoped to any environment they don’t have permissions for). Refer to my attached screenshot showing the error I see. Is this the same error your users see in the same scenario?
The error in my screenshot occurred because unscoped variables would apply to environments outside of their team’s scope. Meaning it’s intentional behavior to disallow a user who is scoped to one environment from adding variables which would apply to other environments. When I removed the team’s scope like you did, then the user could create unscoped variables.
I look forward to hearing back, and please let me know if I’m misunderstanding at all.
The users were getting this error when they were amending the project and adding a variable, it may have been due to where they were trying to scope the variable, I’ll try to do a bit more of an investigation next week to see if I can understand the precise scenario.
The group the users are in has the following roles:
Environment Viewer
Project Deployer
Project Contributor
It is restricted to a project group
The projects have also been added (this isn’t really necessary now as the projects are all part of the group).
We have the same problem. Some variables have the same values for both ST and QA - therefore scoped for ST and QA, for instance. But the users who have rights only in QA will not see those variables. They will see only variables scoped in QA.
The same goes for system variables, like OctopusPrintEvaluatedVariables, that is not scoped to a certain environment. Maybe a variable that is not scoped to a certain env should be seen by all users in that project/team/permission.
And should see the variable whose scop invludes his env.
Thanks for getting in touch! You’re correct that a user who has permissions for only one environment cannot view or edit variables that are scoped to multiple environments, even if one is an environment in which they have permissions for. This is because a change to this variable would affect an environment in which the user does not have permissions for.
An option I might suggest is to split your variable into two separate variables, where you can scope one to this single environment. That way your user will have access to the variable, but only for the environment in which they have permissions for. Otherwise, you’ll need to give the user permissions for the other environments.
There are also permissions specifically for unscoped variables - VariableViewUnscoped and VariableEditUnscoped. You can give these permissions to users as needed for your scenario, but unscoped variables would potentially apply to any and all of your environments. Feel free to refer to our User Roles documentation page that outlines creating custom roles and assigning specific permissions to them.
I hope this helps! Don’t hesitate to reach out if you have any further questions.
”This is because a change to this variable would affect an environment in which the user does not have permissions for”.
This makes perfect sense, we’ll split the variables.
