Permissions question
Accepted answer
Hi,
just caught your question when going through unanswered question 60+ days ...
Meanwhile you probably found the answer yourself:
Adding a user X to the project area as team member does NOT make them a member in any (sub) team area.
Every team area and sub team area can have completely different team members with different roles in each team area. The only things that team areas inherit from the project area is process and roles, but those can be configured differently in team areas, too.
Though late, does this answer your question?
- Arne
just caught your question when going through unanswered question 60+ days ...
Meanwhile you probably found the answer yourself:
Adding a user X to the project area as team member does NOT make them a member in any (sub) team area.
Every team area and sub team area can have completely different team members with different roles in each team area. The only things that team areas inherit from the project area is process and roles, but those can be configured differently in team areas, too.
Though late, does this answer your question?
- Arne
2 other answers
I would suggest to read https://jazz.net/library/article/291 the related article https://jazz.net/library/article/292 and https://jazz.net/library/video/106 because there is some inheritance mechanism in place.
The lookup starts from the process area that governs the operation. For each of the roles that the user plays in the governing process area, we first look for a configuration in the governing process area and then work our way up the parent hierarchy to the project area. If an area configures behavior for different iterations, we choose the configuration that is most applicable to the current point in time. We use the behavior configuration that is found for the first of the user's roles. Now let's break down these steps to see what the implications are.
The text above is for operational behavior. For permissions the user accumulates permissions starting with the team area that governs the operation up to the project area.
If you have configured the Team Configuration of the project area, the sub teams inherit that permission, unless you specifically override it.
Honestly, i have to play with it myself to be sure, i haven't thought about it for some time and I am not convinced I'd get it right the first time currently...
The Eclipse Client provides the "Generate runtime report" on the Project area context menu, that sometimes comes in handy.
The lookup starts from the process area that governs the operation. For each of the roles that the user plays in the governing process area, we first look for a configuration in the governing process area and then work our way up the parent hierarchy to the project area. If an area configures behavior for different iterations, we choose the configuration that is most applicable to the current point in time. We use the behavior configuration that is found for the first of the user's roles. Now let's break down these steps to see what the implications are.
The text above is for operational behavior. For permissions the user accumulates permissions starting with the team area that governs the operation up to the project area.
If you have configured the Team Configuration of the project area, the sub teams inherit that permission, unless you specifically override it.
Honestly, i have to play with it myself to be sure, i haven't thought about it for some time and I am not convinced I'd get it right the first time currently...
The Eclipse Client provides the "Generate runtime report" on the Project area context menu, that sometimes comes in handy.