Variable view and rights

[Nicolas_Gicquel]

Hello
I saw the topic (View variables) and I understand why “segregate Variable editing per environment” is an issue but why can’t you segregate variable view per environment ?
Currently if a variable has ONE value for two env (ENVA, ENVB) with ENVA “allowed to be viewed” by a user but not ENVB, the variable is not seen at all.
Can’t we have something like : ENVA / (Other…) in the UI if you don’t even wan’t to display the env name or just ENVA ?

Thanks.

(Running Octopus v2018.9.9)

[nick (Nick Josevski)]

Hi Nicolas,

Thanks for getting in touch. We’re not sure on your exact objective, maybe some screen shots of how it’s behaving with a highlight of how you think it should work? There may be a way to achieve what you’re after. If you do have a grasp of how the permissions work, and are suggesting an alternative it’s not something we can really consider. Variables are very core to Octopus and we are reluctant to change their fundamental behavior as many customers depend on how they work today.

In case you haven’t considered you can have different scoping per value, so if this is a matter of showing names but not values, you can set it up how I have it highlighted in this screenshot.

Regards,
Nick

[Nicolas_Gicquel]

Thanks for your answer .
My concern was for the “I am scoped to TWO Env” case.
Why the user with “dev env access only” can not see the value for the dev env ? :

Regards,
Nicolas

[nick (Nick Josevski)]

I see. Yes the answer there is that value is used in 2 environments, so it’s of some importance to DEV and TEST A.

If you have decided that the user isn’t allowed to see TEST A then they cannot see something that will end up in TEST A.

The middle case where the variable has 2 values one scoped to DEV and the other to TEST A would be the approach to take. If you need them to be the same value that’s ok too.

Regards,
Nick

[Nicolas_Gicquel]

I understand but it ruins a bit the "multiple scopes’ definition capability in my opinion .
Don’t you think it would be acceptable to show value as in my screenshot ?

Regards.
Nicolas

[nick (Nick Josevski)]

Hi Nicolas,

After some more through we do support the case you’re after, tho it’s not that user friendly.

If you make new User Role and you have it include only VariableView. You can then scope it to the environment you would like them to see variables for - in my example Test A. This will let them see the variables, but because they lack EnvironmentView the will see it as a red chip in the editor.

The question is then why do you need to hide the name of the environment from this user if you’re ready to show them variables? If you have a good answer then go ahead with this approach

With this permission combination (how you can defined in v2019.1):

They will see the following:

Does that get you to the setup you’re after?

Regards,
Nick

[Nicolas_Gicquel]

“why do you need to hide the name of the environment from this user if you’re ready to show them variables”

The initial need is just to show the variable value of the “authorized” env. No need to hide the name of the other env.

What you have shown in your last post is a new feature of version 2019.1 ?

Regards,
Nicolas

[nick (Nick Josevski)]

Hi Nicolas,

Thanks for giving me more info. If you grant EnvironmentView for those other environments, they’ll be able to see the name, but also more details when they go the infrastructure page. Have a go setting up the user with VariableView and EnvironmentView scoped to that other environment.

In the screen shots I showed you how it’s easier to do in 2019.1, because we now support multiple role+scoping combinations in a single team. If you want to achieve the same outcome in 2018.12 and earlier, you just need to create more teams and put the same users in them.

There’s some more info and diagrams in this blog post if it helps.

Regards,
Nick