Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

how to control RRC permissions via team role ?

 We are trying to control RRC permissions via team role to allow a subgroup of users to have only right to modify one attribute (customized "impact attribute") of an artifact (customized "GAP artifact"). 

We tested OK on DEV env with the combination of:

Analyst license + Project role Commenter + team role "GAP impact auditor" 
assuming the more pervasive permission is controlled by the role lower in the hierachy.

However the above combination does not allow any modification in PROD, we need to give the user the project role author, hence it is defeating the purpose since with author the user could then create or modify anything in the project.

We wonder if there are hidden controls on the customized artifacts or attributes which require a different combination to work on PROD:

Analyst license + Project role Author + team role "GAP impact auditor" 
where the team role is just a dummy, inert role.

We are trying a simpler model with a direct project role of "GAP impact auditor" with the more restricted W permission.

CLM 4.0.1 on WAS & DB Oracle

0 votes



2 answers

Permanent link
 Probably have found our own answer.

as follows: Any additional team role should be defined on the project level, i.e. as a project role (but does not necessarily have to play a project role). Then its permissions should be set via Team Configuration (Project area Permissions/Team Configuration) so any team will inherit the permissions thus set. If Final is not checked, then the role can be further configured and restricted through the team area permissions.

In our earlier implementation, we had added the team role in the team area only, hence could it have been inherited from project area level team configuration as "NULL" , i.e. no permissions, so the team role permissions cannot be open up from "NULL" ?

Not sure if it is true that team area permissions can only clamp down permissions further, not to open up.

And if it is true then how has it been working at all in our DEV env. with that first implementation ?
And what could have been the difference between our DEV and PROD ?

0 votes

Comments

would have choosen this answer of mine as the right one for closure if I could have done so.


Permanent link
 We did find our accepted answer as per our own above answer by defining to-be-inherited permissions for Team roles via "Project area Permissions"/"Team Configuration" . However we get another question on this subject.

With further testing we found that we don't need an RRC Analyst licence to modify an RRC artifact, i.e. to write to an artifact: 

Contributor Licence + Project role Commenter + inherited permissions for Team role "GAP Co-Author" ==> Allow modifications to an artifact ==> R/W Privileges 

Is this by IBM design (i.e. we should go ahead and only use Contributor licenses for Project members in this Team role) or is it a loop-hole (i.e. we should actually use Analyst licenses for Project members in this Team role, to avoid issues later with upgrades/updates when IBM decides to close the loop-hole).

0 votes

Comments

I am assuming this has already been answered by Daniel in the other question?

 Yes he did on this piggy back 2nd question. I asked anedw separately as it seemed burried in the first question till now. Thanks Robin.

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,020

Question asked: Oct 22 '13, 1:47 a.m.

Question was seen: 5,681 times

Last updated: Oct 29 '13, 7:31 p.m.

Confirmation Cancel Confirm