Which actions/operations reflect the permissions of an "Administrator"
Hi
In RTC and any other Jazz based application users can be defined as "Administrator" in each project/team area.
In addition the same permissions are provided to a user in case a role like "ScrumMaster" or "TeamLead" is assigned to a user.
In my organisation I have to guarantee that only the "Administrator" can
- add/remove users including their role assignment
In order to achieve this I am searching for the actions in the process configuration that exactly give these permissions and then remove these actions from all the roles.
So far I have found in the Project / Team Configuration -> Permissions the following actions:
Process / Team areas (server) / Modify team areas / Modify collections of team members
Is this the action I am seeking for?
Thank you
|
Accepted answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 30 '17, 12:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Being a project administrator is the same as having the "Process" permission box checked in permissions section of the process configuration page/editor. Marko Tomljenovic selected this answer as the correct answer
|
2 other answers
Ralph Schoon (63.5k●3●36●46)
| answered Nov 24 '17, 2:18 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Nov 24 '17, 2:34 a.m. I think we had the discussion before (https://jazz.net/forum/questions/231048/what-capabilities-does-a-projectteam-area-administrator-have) . The users (with repository role JazzUser) that are maintained in the Administrators section of a process area don't automatically have a role other than the default role or any permission other than the permissions granted to everyone in that area.
Only once they have permissions for roles they have in that area, they can perform these operations.
With respect to the other details, I don't know that by heart, but would assume that you are looking at the right stuff.
As far as I know a lot of the applications share the foundation mechanism, however I would be careful with making the assumption that this will always be the case. I think you have to check for each application if that is the case.
Comments
Marko Tomljenovic
commented Nov 24 '17, 3:59 a.m.
The discussion you were referring to is very related to this question, but the answer that I am seeking is different.
I will check all the applications for the mentioned action and then put a reply here.
Sorry if I didn't get the question right.
Marko Tomljenovic
commented Nov 24 '17, 6:54 a.m.
No problem :)
Marko Tomljenovic
commented Nov 30 '17, 4:32 a.m.
Hi Ralph
I need to come back to this question to get a clear statement. My understanding now is that a project/team area administrator implicitly gets the permissions that someone would find in the process configuration editor under: Project Configuration / Process / Project areas (Server) and Team Configuration / Process / Team areas (Server)
In the end the question is whether the capabilities of an "Administrator" could be fully covered by a dedicated process role (not saying that I want to do it)?
|
Ralph Schoon (63.5k●3●36●46)
| answered Nov 30 '17, 4:50 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER I think the summary here is, that the administrators ALWAYS have the permission to save the process configuration.
Comments
Marko Tomljenovic
commented Nov 30 '17, 10:16 a.m.
Hi Ralph,
Thanks. But this explanation I already understood. Which "Permitted Actions" according to Process configuration editor do you mean when you say "allowed to save process configuration"? Adding users and assigning roles to them does not change the concrete process configuration (xml) of a project area since this data is stored somewhere in the project area data base space/table.
I am sorry for asking that many questions regarding this topic but I found a lot of posts regarding this topic (some of them are even by me) but none has a clear and formal answer related to my question.
|
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.
Comments
Small addition. I need to realize this for all CLM applications: RTC, RQM, DNG, RDM, GC, RELM (that are using the same role based permission model).