Hi,
My company has recently performed the upgrade from octopus 3.17 to 2020.1.15.
What we noticed is that users who were previously able to edit unscoped variables in LibraryVariableSet are not able anymore.
They now get the message: " You do not have the permission to perform this action. Please contact your octopus administrator. Missing permission: LibraryVariableSetEdit"
This permission is already attached to the team these users belong to and is scoped to a specific environment. If I remove the scope of this permission, users in that team are allowed to edit the unscoped variables but also variables scoped to any environment while the scope of permission “VariableEdit” is still on that specific environment only.
Thanks for getting in touch! I’m very sorry you’ve hit this unexpected change in behavior after upgrading. I appreciate you sending through your permissions export. Fortunately this is a known situation, which I’ll explain a bit about below.
This was a breaking change introduced in 2020.1.2 to how LibraryVariableSet permissions (edit & view) worked. The purpose of this change was to provide more granular control over library variable set permissions, to allow these permissions to be scoped by environments and tenants where previously this was a very commonly hit limitation. Before this change, access to these variables in a library variable set relied on scoped EnvironmentView permission, where now they’ve been decoupled and work similarly to how VariableEdit and VariableView permissions work. A lot more details surrounding this change can be found in the following blog post.
In your situation, it looks like all you’d need to do to fix this is add an unscoped LibraryVariableSetEdit permission on a team this user is a member of.
I hope this helps! Let me know how you go or if you have any further questions going forward.
Thanks for the answer.
Unfortunately the proposed solution (add an unscoped LibraryVariableSetEdit permission on a team this user is a member of) indeed allows user to edit/create unscoped variable but it also give the users in that team the right to edit variable scoped to environment they’re not supposed to be able to edit (EG: Production)
Thanks for following up! Firstly let me offer my apologies on my mistake. I think the solution should be to add this permission: VariableEditUnscoped, which should allow you to “Edit non-environment scoped variables belonging to a project or library variable set” (quoting this permission’s description in the UI).
However going through a reproduction of this setup, I’m seeing the user with these permissions not being allowed to edit unscoped variables in the library variable set while simultaneously having environment-scoped LibraryVariableSetEdit permission. At this stage that behavior looks to me to be incorrect, and I’ve raised this with my team to discuss further. I’ll certainly keep you updated with the progress of that conversation, and possible bug report.
Let me know if you have any questions in the meantime.
Awesome,
Thanks for the follow-up. We’ll implement a workaround (yet to be determined) solution in the meantime.
Thanks for letting me know whether this turns into a bug or not when you know the answer so we can decide on the next permission implementation we put in place.
Thanks for your patience on this one. I got some agreements that this looks like a bug so I’ve raised it as a bug report at the following link for you to track.
I wasn’t able to reproduce this in 2019.13.7 so it seems like an unexpected side effect/regression of the variable set permissions changes in 2020.1.2. I’m sorry you’ve been bitten by this issue, and I appreciate your assistance to identify it.
Let me know if you have any questions or concerns going forward!
I’m going to need to backtrack a bit here, and I’m very sorry for the run around I’m putting you through. I just heard back from my colleague (who is most familiar and knowledgeable around our permissions structure) and he has informed me that this change in behavior is in fact as designed.
Previously, users who had LibraryVariableSetEdit permission scoped to only a specific environment (e.g. UAT) were able to edit unscoped library variables and thereby potentially affect production deployments (because unscoped variables can apply to all environments).
As a way forward in your case, the more secure way to model these variables is to duplicate the unscoped variables values in the library set, scoping one to the environment(s) that these users should have access to (e.g. UAT) and the other to the environment(s) that they should not be allowed to affect (e.g. Production).
This is a case where the behavior should certainly be clearer and easier to understand, so we’re considering ways that we could improve on the experience in the future.
I hope this helps, and please don’t hesitate to reach back out with any followup questions or concerns.
Thanks for the feedback.
While I understand the concern about LibraryVariableSetEdit permission, I want to highlight that the main focus to me remains the VariableEditUnscoped permission. I find it very odd that a user assigned to a team that has VariableEditUnscoped permission actually doesn’t have the permission to edit unscoped variable unless it also has the permission to edit any variable (scoped or not).
I find it confusing and it feels like either the VariableEditUnscoped shouldn’t exist or it should actually give you the permission to do what it states (edit unscoped variable).
When it comes to the remark
It feels to me like a reversed approach to solve an issue where instead of being restrictive on critical environment (scope variable that touches critical environment and only gives the right to edit them to a small set of people) we should actually scoped variable to uncritical environment (Dev) and have unscoped variable to UAT and production.
In any case, I don’t want to be too pushy and will accept a No if you definitely feels that your approach is right but I’d like to give it a last try at challenging the idea that a user with VariableEditUnscoped permission may not actually have the right to do so.
Thanks for following up, and I do agree that there’s something here that needs to be changed in some way. I’m not positive what that will be, and I’ve passed on your reply/input to the engineers, but it might just be simply a rewording of the VariableEditUnscoped permission (maybe more?). That’s a big part of this that seems to me to be misleading or inaccurate. Anyway I’ll let you know after we can discuss this in detail.
Thank you kindly for your patience and providing your input based on this situation.
Just another quick followup after discussing this further with my team. We’ve decided to modify the description of the VariableEditUnscoped permission to clarify that it does not apply to library variable sets, to align with the actual and intended behavior. This will be included in an upcoming release soon and hopefully that helps prevent future confusion.
We all appreciate your input (and pointing out this oversight). If you have any questions or concerns in the future, please don’t hesitate to reach out!
