I want to provide our project leads with the ability to change team members as needed. Currently only the Octopus systems administrator can modify teams and their member. I realized it is possible to create custom roles which seemed to be a solution for this problem. I created a role and enabled the following rights in the role:
After the roles has been created I assigned it to a certain team. However, the members of this particular team is unable to see the configuration tab and access teams’ configuration section.
Is it possible to create a custom role that makes it possible for members to administer other teams and members? I do not want to give system administrator access to many people so that they can manage team members. However, what I want is that a few pople can add and remove people from certain groups.
Thanks for getting in touch! So we do not have a specific setting to show the ‘configuration’ tab apart from you must be an administrator. We also do not feel comfortable delving into the permissions or coding that would be needed to add specific permissions to add security around showing it.
That being said, your Team manager users could just go to the location http://localhost/app#/configuration/teams (replacing localhost with whatever your Octopus Server URL is).
The permissions under the tabs will work, and they should be able to see this Teams page and manage it there. People without those permissions will not be able to see the page.
I am trying to do something similar and have followed a similar path. One concern I have is that I don’t see an easy way to prevent the members of this custom team that manages teams from modifying the Octopus Administrators Team as well. In testing this, our test user was able to add himself as an Octopus Administrator and obviously this is something we would want to prevent. Any help would be appreciated.
Brian:
I don’t believe there is a way to prevent this. Anyone granted the right to manage Teams is effectively an Admin. Even if we prevented them from modifying the Octopus Administrators team, they could create a new team with equivalent permissions and add themselves into that.
Basically, if you have the power to assign permissions to Users (which is what adding Users to Teams is), then you are a de facto Administrator.
I’ve got similar issue. Even though the user rights management is pretty flexible, but obviously not flexible enough. I’ve already raised similar question about rights being project centric. In my opinion project should be the root object under which all the project specific configurations should be done like project lifecycle, environments and so on. This way we would not overlap with other teams and we would try to overcome this issue by creating ProjectName Test, ProjectName UAT, ProjectName Prod environments. The team lead should be able to modify team members, remove/add environments of the project. I know it’s a pretty big topic, but if you ever going to review the user management, please check the Teamcity management system.