It's all about the answers!

Ask a question

How does Team Inheritance of Permissions Work?

Andrew Codrington (17733135) | asked Aug 16 '13, 12:27 p.m.
At the top level of a project area we grant pretty broad permissions for Work Items under Team Configuration, but hold back a few including "Remove work item from team area" (Work Items | Save Work Item | Remove Work Item from Team Area).

If I now select a team under that project area, and edit permissions for the team I expected to be able to select that specific permission and additively grant it to roles, maintaining other Work Item permissions granted to the same role at the project area level.

It does not seem like it behaves this way.

Instead we need to re-grant all of the desired Work Item permissions to all the roles within the team.

That was determined though quick experiments. Rather than reverse engineering how these things actually behave I'm hoping there's a writeup somewhere describing how this is supposed to work.

I have a nagging sense I've asked this before, but can't find it if I did. My apologies for any duplication of questions!

Accepted answer

permanent link
Ralph Schoon (63.2k33646) | answered Aug 19 '13, 7:22 a.m.
Please have a look at and the related article about behavior. There is some work being done to make it easier to understand the permissions in the Admin view.

Andrew Codrington selected this answer as the correct answer

Andrew Codrington commented Aug 20 '13, 9:54 a.m.

Thanks Ralph. That article is helpful. I hadn't read it closely the first time around since it's for Jazz 2.0.  There could still be more clarity on the subtleties of this behaviour.

As I understand it, if I want to additively grant a single permission a few layers down in a sub-team (e.g. Work Items | Save Work Item | Remove Work Item from Team Area) I also need to re-grant everything all the way back up to Work Items. I also need to be sure to keep both sets of permissions aligned as permissions are added or removed in future, and repeat the process for all impacted roles. Lots of clicking!

Geoffrey Clemm commented Sep 16 '13, 9:32 p.m.

Permissions are additive, so your permissions are the union of all the permissions of all roles that you have in the team area and all the parent process areas of that team area (plus iteration type permissions, if you've defined any).   So just grant the permission in the sub-team, and you'll be fine.

Note, though, that operation behavior (as opposed to permissions) is not additive, so if you set some operation behavior for some role in some team area, you have to make sure to set all the operation behavior you want to apply to a user in that role (since none of the operation behavior is inherited).   There is a work item for adding inheritance to the operation behavior.

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.