Restricting access to Build Definitions
Hello, I've been trying to configure RTC such that there are a set of Build Engines and Build Definitions that cannot be altered by ordinary team members. We've had problems with people changing "official" Build Definitions that affect the global team.
I've been investigating permissions and Team Areas, and what I've done is for the "Project Area" I've removed the all of the Build permissions from Everyone and "Team members" can do things such as submit builds, and cancel Personal Builds but not edit Build Definitions. In addition, I've added an new role "Build automation" that has all the Build permissions for our build ID to run.
Of course, that would allow nobody to work with build definitions, so under the "Project Area" we have a number of "Team Areas". In addition to the other Team Areas, I've added a "Build Team". This "Build Team" is set as the "Project or Area Team" in the official Build Definitions, the ones I want only a certain subset of people to edit.
However, I find that non-members of the "Build Team" Team Area can edit, save, etc, Build Definitions with no trouble. Does the assignment of Build Definitions to a Team Area mean anything regarding the permissions? I presumed that Build Definitions couldn't be edited by a user if that user is not a member of the Build Definition it belongs to.
Has anyone had any experiences in this area?
Thanks,
Stuart
I've been investigating permissions and Team Areas, and what I've done is for the "Project Area" I've removed the all of the Build permissions from Everyone and "Team members" can do things such as submit builds, and cancel Personal Builds but not edit Build Definitions. In addition, I've added an new role "Build automation" that has all the Build permissions for our build ID to run.
Of course, that would allow nobody to work with build definitions, so under the "Project Area" we have a number of "Team Areas". In addition to the other Team Areas, I've added a "Build Team". This "Build Team" is set as the "Project or Area Team" in the official Build Definitions, the ones I want only a certain subset of people to edit.
However, I find that non-members of the "Build Team" Team Area can edit, save, etc, Build Definitions with no trouble. Does the assignment of Build Definitions to a Team Area mean anything regarding the permissions? I presumed that Build Definitions couldn't be edited by a user if that user is not a member of the Build Definition it belongs to.
Has anyone had any experiences in this area?
Thanks,
Stuart
10 answers
Of course, that would allow nobody to work with build definitions, so under the "Project Area" we have a number of "Team Areas". In addition to the other Team Areas, I've added a "Build Team". This "Build Team" is set as the "Project or Area Team" in the official Build Definitions, the ones I want only a certain subset of people to edit.
However, I find that non-members of the "Build Team" Team Area can edit, save, etc, Build Definitions with no trouble. Does the assignment of Build Definitions to a Team Area mean anything regarding the permissions? I presumed that Build Definitions couldn't be edited by a user if that user is not a member of the Build Definition it belongs to.
I'm not positive, but I believe that setting the owning team area of a build definition should make its permissions be governed by that team area. One thing to keep in mind is that role assignments are inherited down the team area hierarchy. So if your Build Team is a child of some other team area, any roles assignments in that parent team will also take effect in the Build Team.
- Jared
--------------------------
Jazz Team Process
In order to edit build definitions and engines, one or more of the user's assigned role(s) would need to grant permission for the 'Save Build Definition' and 'Save Build Engine' operations (these also have child actions for creating new ones and modifying existing ones). The user's roles are looked up from the process area (project area or team area) associated with the build definition / engine, and all parent process areas are considered.
What are the role assignments in the owning team area(s)? Did you also remove build permissions from the Everyone role there?
What are the role assignments in the owning team area(s)? Did you also remove build permissions from the Everyone role there?
Thanks for your quick response.
In the project area I've removed all permissions from Everyone (default) for Builds and gave "Team Members" some access, so they can submit builds, and to be able to delete and cancel their personal builds. In addition, I've given all of the permissions for Builds to Team Members in the Team Areas.
It sounds like it ought to work the way I think it should based on what I've seen. However, all it appears to affect is the "Project/Team Area" attribute. Any other attributes of the Build Definitions can be edited and saved by non-members of the team.
In the project area I've removed all permissions from Everyone (default) for Builds and gave "Team Members" some access, so they can submit builds, and to be able to delete and cancel their personal builds. In addition, I've given all of the permissions for Builds to Team Members in the Team Areas.
It sounds like it ought to work the way I think it should based on what I've seen. However, all it appears to affect is the "Project/Team Area" attribute. Any other attributes of the Build Definitions can be edited and saved by non-members of the team.
Which process template are you using, and do the users in the project also have the 'Team Member' role? The roles are just ids, and don't actually represent a list of users, other than via the explicit user / role assignments in the team area and its parent process areas. The one exception is the Everyone role, which covers everyone (member or not).
We are using the Scrum process template "scrum2.process.ibm.com".
The users have "Team Member" roles.
From what has been said so far and from what can be inferred, the permissions should work the way I expect them to. I had thought I was missing a piece of information, but I'll see if anyone has opened any defects that might be relevant.
The users have "Team Member" roles.
From what has been said so far and from what can be inferred, the permissions should work the way I expect them to. I had thought I was missing a piece of information, but I'll see if anyone has opened any defects that might be relevant.
> The users have "Team Member" roles.
In both the project area and the team are, or just the team area? Anyone with the Team Member role, whether assigned in the project area or team area, will have permissions assigned to that role in the team area (if permissions are overridden there) or the project area (otherwise).
For example, with project area P and team area T, users U1 and U2, and role R arranged as follows:
Then both users U1 and U2 have the permissions for the R role for operations against the team area T (even if R is called 'Team Member').
I suggest removing the permissions to Save Build Engine and Save Build Definition from the Team Member role, and assigning these to a new 'Release Engineer' role, and only assign that role to users you want to allow to save the definitions/engines.
For more on how process permissions are looked up, see:
http://jazz.net/library/article/32
In both the project area and the team are, or just the team area? Anyone with the Team Member role, whether assigned in the project area or team area, will have permissions assigned to that role in the team area (if permissions are overridden there) or the project area (otherwise).
For example, with project area P and team area T, users U1 and U2, and role R arranged as follows:
P (U1: R)
T (U2: R)
Then both users U1 and U2 have the permissions for the R role for operations against the team area T (even if R is called 'Team Member').
I suggest removing the permissions to Save Build Engine and Save Build Definition from the Team Member role, and assigning these to a new 'Release Engineer' role, and only assign that role to users you want to allow to save the definitions/engines.
For more on how process permissions are looked up, see:
http://jazz.net/library/article/32
All of our developers have "Team Member" roles in the Project Area and the "Team Area".
The problem then is quite clear from what you've described.
I want only members of the "Build Team" team area to be able to save/edit build definitions. But as I'm set the "Team Member" role as having permissions to do so in the "Build Team", that means that any other user with the "Team Member" role has permissions to edit the build definitions.
It sounds like a solution is to do as you suggested and create another role that does have the necessary permissions.
I have to say though, it does make my wonder why you would have a hierarchy of teams, and not use that same hierarchy to compartmentalise what the permissions themselves were applied to. i.e. If I'm given permissions to launch builds in Team Area A, why not have that just allow me to launch Team Area A builds?
Thanks.
The problem then is quite clear from what you've described.
I want only members of the "Build Team" team area to be able to save/edit build definitions. But as I'm set the "Team Member" role as having permissions to do so in the "Build Team", that means that any other user with the "Team Member" role has permissions to edit the build definitions.
It sounds like a solution is to do as you suggested and create another role that does have the necessary permissions.
I have to say though, it does make my wonder why you would have a hierarchy of teams, and not use that same hierarchy to compartmentalise what the permissions themselves were applied to. i.e. If I'm given permissions to launch builds in Team Area A, why not have that just allow me to launch Team Area A builds?
Thanks.
The inheritance of process permissions allows you to configure permissions at project level (or parent team area level) without having to configure each user with cross-team permissions into each team area. For example, say there's a buildmeister role that should have access to all builds. You can assign that role to the relevant users once at project level, rather than having to do so in each team area.
This follows the intended design of process permissions, and is not unique to Build operations.
This follows the intended design of process permissions, and is not unique to Build operations.