Problem with permissions since 2018.4.9

We upgraded to 2018.4.9 this morning and we are now having issues with permissions when editing variables.

I can reproduce the issue by creating a User Role that only has VariableEdit and VariableEditUnscoped permissions. I assign a Team to this role and as soon as I try and restrict it by Project or Environment I get the following error on screen when editing a variable:

"You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: VariableEdit

This action requires permission to edit variables belonging to a project. At least one of your teams has this permission in a limited scope, but this doesn’t cover the project or environment in question. Teams that have enough permission include: …"

I have tried adding all Projects and all Environments individually but still get the same error. It’s only when I leave the Projects and Environments blank does it work.

This has meant I have had to give our support team a wider range of permissions than they need so a speedy resolution would be appreciated!

Thanks
Adam

Hi Adam,

Thanks for getting in touch,

I’m sorry to hear you are experiencing this issue, I’m conscious that your current workaround is not ideal so I’m hoping we can resolve this ASAP.

I’ve not been able to replicate this same issue in my own instance at this stage, unfortunately.

If possible, can you please provide an Export of one of the associated Users permissions (prior to relaxing the restrictions?), you can produce this information via Configuration > Test Permissions in the Octopus portal. You’ll need to specify the User here and an option for Export will appear in the top right.

It would also be valuable if you could include a screenshot of the associated error itself and the Team settings found via Configuration > Teams related to this user.

Finally, can I also please confirm which version of Octopus you originally upgraded from?

I look forward to hearing back from you, your patience and understanding are greatly appreciated :slight_smile:

Kind Regards,

Reece

Hi Reece,

Here is the exported user permissions:

Permission,RestrictedToEnvironmentNames,RestrictedToProjectNames,RestrictedToTenantNames,RestrictedToProjectGroupNames
ArtifactView,
CertificateView,
DeploymentView,
EnvironmentView,
EventView,
InterruptionViewSubmitResponsible,
LibraryVariableSetView,
LifecycleView,
ProjectGroupView,
ProjectView,
ReleaseView,
TaskView,
TeamView,
TenantEdit,
TenantView,
TriggerView,
UserRoleView,
UserView,
VariableEdit,Live|Sandbox,PA Tenant Config|PB|PC|PC IP,
VariableEditUnscoped,PA Tenant Config|PB|PC|PC IP,
VariableView,Live|Sandbox,PA Tenant Config|PB|PC|PC IP,
VariableViewUnscoped,PA Tenant Config|PB|PC|PC IP,

Here is the screenshot of the error:

Here is the screenshot of the Team configuration:

I have edited the screenshots and exports to hide the names of internal projects.

Finally, the version of Octopus we upgraded from was 2018.3.6

Regards
Adam

Hi Adam,

Thanks for getting back to me and the time invested in putting this information together, this really helps out!

I’ve been able to successfully replicate the same issue you are experiencing.

From my investigation, This seems to have been inadvertently caused when implementing a bug fix that was resolved in 2018.4.7 as when using 2018.4.6 I’m not experiencing the issue.

I’ve linked this associated issue below;

I’ll have a chat with the Team regarding this in our morning catch-up and will get back to you ASAP with the steps moving forward.

I greatly appreciate your patience and understanding in this matter :slight_smile:

Kind Regards,

Reece

Thanks for the update Reece.

I look forward to hearing the outcome of the morning catch-up.

Hi Adam,

Thanks for your patience,

As previously mentioned, I had a chat with the team regarding this in our catch-up.

I’m going to make a Github issue for this (which I’ll link here ASAP) to address this, as it does seem to be related to the change in 2018.4.7 as outlined above.

In the interim of a permanent resolution, as a workaround you can either;

  1. Rollback to 2018.4.6 (ensuring a database backup is taken prior), please be aware, however, that you will then be susceptible to the bug I outlined previously, please have a read of this issue for more information.

or

  1. Stay with your current workaround by not providing scoping to Projects/Environments, (though I’m conscious this is not ideal as you’ve mentioned.

I don’t have ETA on a permanent resolution at this stage, however, I have flagged this as a concern with the Team and have left a personal note to update this case when this is resolved, additionally the associated Github issue will be the best place to keep up-to-date on the progress.

I’ll include the link here shortly.

Please let me know if you require any further assistance or clarification :slight_smile:.

Hopefully, we can resolve this issue promptly. I’m sorry for the inconvenience caused as a result.

Kind Regards,

Reece

Hi Adam,

Sorry for the delay getting back to you, due to the Public Holiday yesterday this pushed our response time back.

I’ve included a link to the aforementioned Github issue below;

You can keep up to date with the progress of this issue here :slight_smile:

As previously mentioned, if you require any further assistance or clarification, please let me know :slight_smile:

Have a great day!

Kind Regards,

Reece

Hi Reece

I can see that the GitHub issue has been closed as this is “by design”. I’ve added a comment as to why this design doesn’t make any sense but I don’t know if the dev will see this as the item is closed.

Can you make sure the dialogue around this issue stays open until an acceptable way forward is reached?

Thanks
Adam

I am having a similar issue giving permissions to one of our QA engineers, who has the appropriate permissions to view machines, but we get an error:

“At least one of your teams has this permission in a limited scope, but this doesn’t cover the project or environment in question.”

What limited scope? Where?

Hi Adam,

Thanks for getting back to me, I appreciate you following this up.

I had a chat with the Team about this in our catch up and highlighted this again as a concern.

At a high level, how I would personally imagine this to work is that provided the logged-in user’s team is scoped to ALL the current Projects connected to the Tenant then editing the Common Variables is acceptable as any changes here would otherwise affect unscoped Projects.

In scenarios where new Projects are connected to the Tenant, then it should prompt an error to indicate that a Project exists that is scoped to your Team to be clear where the problem resides. (Though that’s just my own thoughts on the matter)

I’ll update you again shortly as I believe we’re still in the process of working out how we’re going to handle this.

I will get back to you ASAP, your patience and understanding in this matter are greatly appreciated :slight_smile:

Kind Regards,

Reece

Hi Adam,

Thanks for your patience,

I just wanted to touch base to let you know this hasn’t fallen to the wayside.

We’re currently working on a solution for this, I’ll let you know ASAP what this looks like. I’ll also link the associated Github issue also when possible.

Speak to you soon :slight_smile:

Kind Regards,

Reece

Hi Adam,

Thanks for your patience, I was out of the office yesterday, apologies for not getting back to you sooner.

I’ve spoken with the team and it appears this in the road map to be included in 2018.5.2 as per the associated Github issue below;

Please let me know if you require any further assistance, when available I’d recommend updating to this version. As always, please ensure a database backup is taken prior to the upgrade, however.

I hope this helps!

Kind Regards,

Reece

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.