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
2 answers
Probably have found our own answer.
Interpreted forum post https://jazz.net/forum/questions/26535/team-permissions-vs-project-permissions
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 ?
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).
