It's all about the answers!

Ask a question

Restricting access to Build Definitions


Stuart Monteith (211) | asked Nov 05 '10, 2:28 p.m.
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

10 answers



permanent link
Jared Burns (4.5k29) | answered Nov 05 '10, 2:43 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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

permanent link
Nick Edgar (6.5k711) | answered Nov 05 '10, 10:02 p.m.
JAZZ DEVELOPER
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?

permanent link
Stuart Monteith (211) | answered Nov 08 '10, 9:47 a.m.
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.

permanent link
Nick Edgar (6.5k711) | answered Nov 08 '10, 10:01 a.m.
JAZZ DEVELOPER
Just to be clear, when you assigned permissions in the team area, what roles did you use? A custom role, or Everyone? If Everyone, then that will apply to everyone, not just team members.

permanent link
Stuart Monteith (211) | answered Nov 08 '10, 5:02 p.m.
I applied the permissions to the "Team Member" role. I am assuming that it would just be Team Members in that Team Area that would gain the permissions, and not Team Members in any other Team Area.

permanent link
Nick Edgar (6.5k711) | answered Nov 08 '10, 5:32 p.m.
JAZZ DEVELOPER
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).

permanent link
Stuart Monteith (211) | answered Nov 11 '10, 10:07 a.m.
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.

permanent link
Nick Edgar (6.5k711) | answered Nov 11 '10, 11:29 a.m.
JAZZ DEVELOPER
> 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:
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

permanent link
Stuart Monteith (211) | answered Dec 14 '10, 10:53 a.m.
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.

permanent link
Nick Edgar (6.5k711) | answered Dec 14 '10, 12:44 p.m.
JAZZ DEVELOPER
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.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.