Staging variables are missing from variable sets for new Team when project list is defined and not missing when project list isnt defined

(jsphillips) #1

Recently we have provided staging variable access to a group of users. I want to lock this down to a select list of projects however the issue I am running into is this. If I leave the project section in the team unscoped they are able to edit the variables hard coded to the project along with the variable sets attached HOWEVER if I put a project list in here they are only able to edit the hardcoded variables for staging inside of the projects only. When they go into the associated variable sets that are attached to the project the Staging variables are missing from view completely. Please advise as to why the variables are missing ?

(Kenneth Bates) #2

Hi,

Thanks for getting in touch! I’m sorry you’re hitting this roadblock. I’ve tested this on my local instance running Octopus 3.14.1, and I haven’t been able to reproduce this behavior. My user is able to successfully view and create variables (in my project and set) scoped to my Staging environment. Both when I leave the project section in my team unscoped (like what works for you), and also when they are scoped to specific projects.

Which Octopus version are you currently running? We’ve made updates recently around variables, so it’s possible an upgrade will fix this.
Can you attach an export of this user’s permissions so I can ensure I’m reproducing your scenario as accurately as I can? You can get that in your web portal under Configuration > Teams > Test Permissions, as shown in our troubleshooting guide.

I look forward to hearing back!

Best regards,

Kenny

(jsphillips) #3

At the time of this post i was running 3.3.27 however now we are running 3.14.1. The odd thing is the fact that the permissions as is work but when putting projects in it kills the variable set stg view.

I have attached a user who is in a group which is added to the team with this access. This same group is also in a view only group for higher level environments past staging.

Permissions_export_2017_06_20__17_50_01_UTC.csv (2 KB)

(Kenneth Bates) #4

Hi,

Thanks for following up and providing that information. Sorry about the delay in getting back to you. Sadly I still haven’t been able to reproduce this behavior (running 3.14.1) after configuring permissions to exactly match as your export shows. My user is able to view/edit variables scoped to my staging environment in my variable sets before and after scoping their teams to a project.

Would you be able to attach a recorded gif of the behavior you’re seeing? This gif can be captured using ScreenToGif, and the process is shown in our documentation.

Specifically I’d like to see -

  • This user viewing variables in a variable set which are scoped to your staging environment,
  • Scoping the team to a project, showing which team is being scoped to which project, and
  • What the user then sees when trying to view the staging-scoped variables in your set

Out of curiosity, are you seeing this same behavior on a different browser, and are there any other factors that could be related in any way?

I look forward to getting to the bottom of this!

Best regards,

Kenny

(jsphillips) #5

Kenneth -
I didn’t yet test with the new version of Octopus 3.14.1. I just got done testing and have found a solution I am comfortable with but one I still am curious about which you may be able to clarify.

So with the new version i was able to scope the team to multiple projects and then login with a test account under that team and test. I was able to go into the projects and edit staging variables only correctly. When i tried to edit the other non staging variables in the project i was not able to correctly.

Here is the kicker, when i went into an attached variable set i was not only now able to see staging but i was able to edit them correctly. I was also able to edit every other non staging variable inside those variable sets as well ! sys,prod,para,sprint, etc… even though the team was only scoped to staging. So that is something you guys may want to look at. The permissions were the same as I sent you before. I would think that the variable sets would be locked down to edit just staging as well right ?

I removed the variableset edit permissions from the team which in hindsight should have never been given even for staging. I think variable sets should only be edited by administrators since multiple projects utilize those sets. So at this point i have removed that and they can edit the hard coded staging variables and view the sets along with seeing staging without issue which is the way i want it to be going forward.

(Kenneth Bates) #6

Hi,

Thanks for following up! I’m sorry again about the delay as I continued attempting to reproduce this. I’m glad you have a comfortable solution going forward!

What I’ve found is the EnvironmentView permissions are what is determining which environment-scoped variables within a set are viewable/editable. Where the scoping on the Variable permissions should be what dictates which variables are accessible. I’ve raised the following issue to get this resolved.

Thanks for your patience, and please don’t hesitate to reach out if you have any further questions!

Best regards,

Kenny

(Jay) #7

Hey OD,

As per:

https://help.octopusdeploy.com/discussions/questions/12074-why-library-variable-set-permission-is-unscoped

can we get an update on this issue please?

We just upgraded from (very old) 2.6.4.951 to 3.16.4 and this is previously working functionality that has since been broken.

I have just granted read-only access to our auditors who are losing their minds over our developers now having the ability to create and modify production variables. The only alternative that you have provided is that our developers be restricted from seeing anything to do with production environments whatsoever.

In 2.6, developers could modify library variable set variables that were scoped to sub-production environments (as per their team access), but could not modify or create variables scoped to production.

The issue was created in June, assigned in July, but has since gone quiet. I’d like to tell my auditors that the fix is scheduled for an upcoming release. What shall I tell them?

Thanks,

Jay

(Nick Josevski) #8

Hi Jay,

Sorry about the frustration this issues has caused. We’re working on a fix and it will be available next week.

Regards,
Nick

(Nick Josevski) #9

Hello,
We shipped a patch for this in today’s release, 3.17.1 available here: https://octopus.com/downloads

Thanks for your patience, if you have any other issues let us know.

Regards,
Nick

(Jay) #10

Great news! Thanks very much, Nick.

(system) closed #12
(Nick Josevski) #13

As an update to this old issue.

As of Octopus Server 2020.1.2 the scoping capabilities of LibraryVariableSetView and LibraryVariableSetEdit will support scoping to Environment and Tenants.

The full details are in this blog post: https://octopus.com/blog/libraryvariableset-permission-changes