You can't modify Common Variables because you don't have access to all projects and/or all environments this tenant is connected to

Octopus Server
1

Octopus Variables can be set up on a project, where the values can be scoped based on various things; but not Tenants.

They can also be set up as Project Template variables, which then requires a value to be supplied for each combination of environment and tenant (but not scoped in any other way).

They can also be set up as a Library Variable Set, which can contain variables directly, or define Variable Templates, which allows you to define variables whose values will be defined per Tenant (but not scoped in any other way).

It’s this last one that this issue relates to. We are trying to define some variables whose values will vary per Tenant; but are not affected by anything else. So we created a new Library Variable Set, added a Variable Template to it for one variable; and then added the Variable set to the project in question (which is currently only linked to a single tenant in Live; but there are soon going to be 3 - hence the need for the variable).

Once we have done, this, the “Tenants” page correctly shows the orange warning triangle to represent that we haven’t filled in the value for one of the Tenants that the project is associated with.

So we click-through, following the orange triangle to the place where we need to fill in the value for the newly-added variable. But when we try to save it, we get the error message given in the title: “You can’t modify Common Variables because you don’t have access to all projects and/or all environments this tenant is connected to.”

I know that other projects are using this Tenant and I don’t have access to those projects; but the thing is that none of those projects are using this Library Variable Set (I know, because I just created it). Is this fixed in a more recent version? Or is there some way of working around this? Please help.

We’re using v2018.12.1

2

P.S. this is exactly the same issue that I referred to as an “aside” in this post 4 months ago: https://help.octopus.com/t/500-error-previewing-variables-when-unset-tenant-template-variables/24243
which I was reminded of because we just had exactly the same 500 internal server error which that post refers to.

4

Hi Richard,

Thank you for getting in touch and for your thorough explanation of your great question. Firstly I’d like to apologise about the lack of a response on that previous thread you posted months back. It looks like it completely fell through the cracks, and I’m very sorry you didn’t get a reply on it.

To understand this better I set this up in my local instance (running latest - 2019.13.7), which I was able to reproduce. At this stage I think what you’re hitting is in fact the intended behavior. Common variables as you’ve mentioned are a way to define values per tenant irregardless of anything else (a common example is an alias).

I imagine the justification for this behavior in this case, where the common variable template is defined in a single variable set which is included in only one project, would come down to the potential for this variable set being added to another project (outside of your permission) by someone else, which would then have the likely unexpected result of setting this tenant-specific value automatically which could potentially be dangerous.

So I think the best answer is to configure this as a project template variable to define these values within the scope of your permissions.

Hopefully some good news about your other issue with the 500 error when previewing these variables via the API, I haven’t been able to reproduce this issue in 2019.13.7 so an upgrade should hopefully fix that up for you.

I hope this helps, and please let me know if I’ve mistaken anything about your situation or have any other questions. :slight_smile:

Best regards,

Kenny

5

Thanks for the reply. The key word there is “the potential for this variable set being added to another project”. Given Octopus’s dynamic approach (e.g. the orange warning triangles, which only appear on the relevant things based on combination of which projects use variable sets and which tenants they use), I would have expected it to be paying attention to the fact that the variable set is only being used by things I have permission to. And sure, if someone then adds the variable set to their Project that I don’t have permission, then certainly it should be locked down with this error message.

This “by design” means that if another project [that I don’t have permissions on] uses the same tenants as I do, then basically this makes the whole Variable Sets feature unusable, either for globally shared variables or ones that are just intended for my projects.

The “Project Variable Template” approach (which was suggested as a work around) leads to a large amount of work to create/maintain the values, since we have to duplicate the value for each combination of project and environment; and we can’t re-use the value across projects, so we have to then duplicate that effort for every project that we want to do that for… not a happy solution.

For the benefit of other victims of this design decision, I’m working around this as follows (it would still lead to duplication across projects; but at least Octopus will allow us to do this, and it reduces the maintenance costs)… one of our existing Variable Sets contains a variable template called “Tenant.ShortCode”, whose value varies per tenant (which is lucky, because we would not be able to create this now, due to exactly this design “feature”). We can use those codes to allow us to set variables which are scoped to a Tenant directly within the project.

Let’s imagine I want to set a “StartTime” variable whose value will need to very per tenant. Firstly, I add the variable set which contains the definition of “Tenant.ShortCode” to my project. Then I create a normal project variable in my project called “StartTime”, and I give it the value “#{StartTime[#{Tenant.ShortName}]}”. Then I define a new variable for each Tenant’s value of Tenant.ShortCode. For example, if the Tenants that I am using have ShortCodes of “A”, “B”, and “C”, then I would define project variables of “StartTime[A]”, “StartTime[B]” and “StartTime[C]”, containing the values required by each tenant.

Good to hear about the 500 error, maybe you could update that other post to say you think it’s fixed in that version, in case anyone finds that question on Google.