Recently we have noticed that creating a new team in octopus with admin permissions for specific environments that has not functioned as expected.
Most of our deploy users are in this group and they contain the “System administrator” role. We then lost the ability to view variables that were already there, create new or edit existing variables.
We could not see why this would be so upgraded from 2.3 to 2.4.9, which seemed to solve this particular issue…
Today we have noticed this is occurring again, but the permission errors are occurring with environments not variables. Upon trying to add a new environment the option to add no longer appears and trying to upgrade tentacles fails with a permission error.
Is there anything we can do to try and resolve this?
Thanks for getting in touch!
Could you please provide us with some screenshots of your teams/roles.
Not really sure what is going on here, so hopefully that will help us get to the bottom of it!
The odd thing is that even adding the users to the “Octopus Administrator” team did not resolve this issue, although when we used the URL to directly add an environment we could do it this way, so the link was hidden but functionality not disabled.
We only have a single member in the “Octopus Administrator” team, and all the roles are as default. We have only used teams and not roles.
Unfortunately I can’t get too many pictures of our teams as it would disclose sensitive information. Is there any screenshots in particular you are after?
Is there a tool to test a user and evaluate their permissions and display them? I’ll test this via the API if I can.
Okay lets start with the Octopus Administrator.
Under Teams then the Roles link at the top, find the Octopus Administrator role and just confirm that everything is still ticked for me.
We do have a tool that traces permissions but its more to do with AD authentication, I’ll track it down after you confirm that everything ‘looks’ right.
I have looked at the “System administrator” role. The team is “Octopus Administrators”. I think this team and role are the default?
The “System administrator” role has all the permissions ticked. If I try and save this role then I see a “The built-in system administrator role can’t be edited.” message.
Strangely at the moment my user has permissions to edit the teams and users and re-add myself as a “Octopus Administrators” but when I view the environment list I do not have the ability to add a new environment?
As a general rule, can users be part of multiple teams that may overlap in permissions?
Okay so there is one thing it could be, which is RavenDB indexes are out of date. So if you could try the RavenDB repair link on the Octopus Manager.
If that does not resolve your issue, we will need some logs which you can find at:
C:\Octopus\Logs (where Octopus could be installed somewhere else, but the logs directory is off the main install directory).
I will need one of the OctopusServer.txt files. These are rolled over, so if you find a date that matches when you are having these issues (or log in and try to navigate around the environments tab etc).
If again this includes sensitive information could you email it to vanessa at octopusdeploy dot com ?
We will get to the bottom of this!
I have just performed the RavenDB repair and this performed successfully but has not changed the problem.
Looking through the OctopusServer.txt file there is no information that seems to help, it is mainly release retention updates and server health.
If I add my user to the “Octopus Administrators” team, then try and edit and environment I do not see the link, but if I visit:
“app#/machines/new?environment=Environments-X” where ‘x’ is the environment number, then revisit the environment page I now get the ability to add an environment. This only happens when I re-add myself to the “Octopus Administrators” team.
We have two separate teams because by default we are full admins for everything except deploy to production, which only a specific user can do.
We are pretty stumped. Our stab in the dark leftovers are:
- some kind of weird db corruption
- browser caching/proxy issues
Where to go from here:
a. 2.5 has some permissions browsing added to try to help with permissions issues - might help with tracing?!
b. somehow you give us a very specific breakdown of your users/roles/teams without divulging any of the sensitive information
c. book a Skype call to screen share and we try to find the issue here, but based on your hesitance to show us screenshots or logs, would you be open to this?
How would you like to proceed?
Strangely, we do seem to be in fairly stable state now with the environments. It does seem to be working consistently now after giving it some time after doing the ravenDB reset.
The only bug now I see is the way with that environment permissions are handled… At the moment I am a system administrator in a team, restricted to specific environments.
If I add the environment manager role to a team, it contains the following text:
“Create environments (restrictable to environments)” - How can creating environments be restrictable to environments? Given that being a environment manager is separate from any environment restrictions?
Given the above, I think this is where we are seeing our confusion. We essentially have two teams, set-up like:
- Admin (Environment is restricted to all except live)
- Admin (No Restrictions)
If I add myself to the non-restricted admin team from the other admin team, then I get the ability to add / edit environments. If I am not a member of the non-restricted team then I lose this ability.
Presumably the environment restrictions of the first group are limiting me from adding new environments even though I am an System Admin and can happily add myself back into the non-restricted team?
Would it be OK to assume that the environments should not be restricted in this case and be handled separately when the user is in the system administrator role?
I am glad the permissions issues sorted themselves out, when those RavenDB indexes need updating they really need updating!
As for the rest. We have had this issue come up a bit about being able to create new environments if you are restricted to specific environments, and right now it is working as intended for majority of users.
You are correct because you are restricted to Environments you cannot then make new environments as its out of your ‘range’ even though you can do as you say add yourself to the other group, make one then change yourself back. Mostly with restrictions majority of users have to have Environments created for them because they don’t have that type of access…
But we think we have an idea for a potential way to make everyone happy that right now is a UserVoice Submission.
The idea is to allow for Environment Groups, thus be assigned to an Environment Group then you can create Environments within that group if you have the correct rights without being a full administrator.
So you can find that here: http://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5731235-environment-groups
Go and vote and comment and tell your friends!
Thanks for the response. I just thought the environment permissions were slightly confused given that I was an admin but your response makes sense.
We could certainly rework our current process to use a manual intervention step for live deployments rather than teams and roles given it appears to make slightly more sense, I think.
That way we can at least see what version production is on and see how far the environment is potentially behind. Thanks for your help!