It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×12,008
×3,952

question asked: Oct 22 '13, 1:47 a.m.
question was seen: 5,597 times
last updated: Oct 29 '13, 7:31 p.m.

Related questions

how to control RRC permissions via team role ?

0
long TRUONG (365●4●123●147) | asked Oct 22 '13, 1:47 a.m.
 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

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
long TRUONG (365●4●123●147) | answered Oct 22 '13, 7:53 a.m.
 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 ?

Comments
long TRUONG commented Oct 29 '13, 4:51 p.m. | edited Oct 29 '13, 4:51 p.m.

would have choosen this answer of mine as the right one for closure if I could have done so.
0
permanent link
long TRUONG (365●4●123●147) | answered Oct 24 '13, 9:09 a.m.
 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).
Comments
Robin Bater commented Oct 29 '13, 7:09 p.m.
JAZZ DEVELOPER

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

long TRUONG commented Oct 29 '13, 7:31 p.m.

 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 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.