Teams scoped to environments don't see all variables

Marius's Avatar


11 Jan, 2018 04:36 PM

How to reproduce:
* Create at least three environments
* Create a variable set with a variable, and scope it to all three environments
* Create a team scoped to only one variable
* Create a user with an api-key and add it to the team
* Using the api, get the variables for the variable set

What happens
* The variable that is in the environment is not returned

What should happen
* The variable that is in the enviroment is returned

It seems like a team needs to have all the environments that a variable is scoped to, to be able to view it. I would expect the variable to be viewable when the user has access to at least one of the environments the variable is scoped to

  1. Support Staff 1 Posted by Nick Josevski on 15 Jan, 2018 12:09 PM

    Nick Josevski's Avatar


    Thanks for getting in touch.

    I'd like to make sure we're on the same page in discussing this, because permissions in Octopus can be confusing. The web UI uses the exact same API calls you would using a client and an API key, so if the API you called looked like https://your.octopus/api/variables/variableset-LibraryVariableSets-XX we're talking about the same thing, it won't matter if you load it via the UI or via an API call.

    Next, lets talk concrete environment names for the 3 in your example, lets say we have Development, Staging and Production, and as an example the variable of concern is the connection string to the database which isn't to be known by everyone in some of the environments.

    I make a user that can only see Development because that's the only concern they should have, it's ok they see that connection string, but they shouldn't see the other 2. I've created that scenario, in this case the user on the right (with restrictions) cannot see Staging or Production.

    So for the case where I have 3 variables with different names, they only see the one they can access. For the other one which is a single variable but with all 3 scopes, it means we're using it Staging and Production but this user can't see those environments so they shouldn't see the variable at all, even though they know about Development.

    This scoping applies to project variables the same it does to those in variable sets.

    See screenshot 'scoping-sets.png'.

    This leads us to the question, what's your real world objective?

    You can have a variable with repeated names, and in Octopus v4, we'll group it nicely in the variable editor, like in my screenshot, this way for each value you can scope it and then it can be viewed and edited, this is what we would recommend.

    If you're after more, and you would like the user to be able to edit the Development variable and view Staging and Production, then you'll need to do a bit more work configuring their permissions. At the moment because of how the permissions work, this will require extra teams, you will need to make another team that will have roles that provide view access, and scope them to the other environments.

    If I misinterpreted your query let me know, including sharing the API you're calling, and screenshots of you logged in as that user or a user with the exact same permissions.


  2. 2 Posted by Marius on 15 Jan, 2018 07:12 PM

    Marius's Avatar

    Hey, thanks for a very thorough answer. You understood my question exactly.

    The problem for me is that it works a bit counter-intuitive, or at least very different from other systems. If, for example, I create a folder in linux and make it visible only to some groups, then a user which is part of any one or more group will see it. Same with user roles in AD, I don't have to be a member of every role to have access to something, I only need to be a member of one role to see it.

    But that's not how it works in octopus. The user is part of the Development scope, but cannot see the development variable. It means that it works differently for machines (that I want to deploy to) and humans, as a machine is a member of only one scope (Development) and can see the variable, but a human limited to the same scope cannot.

  3. Support Staff 3 Posted by Nick Josevski on 16 Jan, 2018 01:24 AM

    Nick Josevski's Avatar


    That's right, it's not like a file system permission which would combine them with an 'OR'. For variables inside Octopus we use 'AND', and there's a few historical reasons it evolved like this.

    It maps to how we determine the specificity; the further you scope a permission the fewer places it applies, the permissions for viewing match. The more scopes applied the fewer people can see it. It's so many people with different levels of access can work together and we can secure the most sensitive values.

    This approach to the variable permissions won't be changing, so our recommendation is to name your variable, e.g. "Database Connection" and give it a value, per scope, this way.

    The permission system including variables has a learning curve, but once you understand the approach we've taken you can just repeat the patterns learnt.


Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac