updating RQM Roles & permissions through the Eclipse Cli

That is correct. A user's repository level permission is independent of a a users role in a governing project. A users repository level permission is applicable repository wide and it simplify defines the write capability to that server. (i.e A Jazz.USER is the minimum repository permission required to "write" to a repository", and most users would be assigned this repository permission.)

The assignment of a users repository role is an admin level task for when the user is added to the repository. Thereafter its up to the users memberships to a project area, and their applied roles in that project area that actually define their capabilities.

Modifications to update a project areas process (including roles/permission) is itself governed by project operations. To put restrictions around it require configuring the roles to define the capabilities of that role for that project area.)

Out of the box, RQM is an open system, where the default process role allows all operations and its up to the admins of that project area to define how they want to govern their project area.

The three levels of the underlying permission checking that occur are for any operation are..

(1) Does the user have write access to the server (i.e Jazz.USER)
(2) Does the user have the appropriate license to perform a given operation.
(3) Does the user have the appropriate role to perform that operation in the context of the project/team area.

Hope that helps. More detained explanation on the Jazz Team server permission capability can be found in the in jazz.net library.

Thank you Sachin,

1. The point is; I thought I HAD put restrictions around the roles. I went into RQM Admin Project Administration & restricted the roles & added members to the project. As I said, this user is a JazzUser with a "tester" Role & restricted permissions, & I do not think he should be able to change his role?

That is correct. A user's repository level permission is independent of a a users role in a governing project. A users repository level permission is applicable repository wide and it simplify defines the write capability to that server. (i.e A Jazz.USER is the minimum repository permission required to "write" to a repository", and most users would be assigned this repository permission.)

The assignment of a users repository role is an admin level task for when the user is added to the repository. Thereafter its up to the users memberships to a project area, and their applied roles in that project area that actually define their capabilities.

Modifications to update a project areas process (including roles/permission) is itself governed by project operations. To put restrictions around it require configuring the roles to define the capabilities of that role for that project area.)

Out of the box, RQM is an open system, where the default process role allows all operations and its up to the admins of that project area to define how they want to govern their project area.

The three levels of the underlying permission checking that occur are for any operation are..

(1) Does the user have write access to the server (i.e Jazz.USER)
(2) Does the user have the appropriate license to perform a given operation.
(3) Does the user have the appropriate role to perform that operation in the context of the project/team area.

Hope that helps. More detained explanation on the Jazz Team server permission capability can be found in the in jazz.net library.

When you configured the tester role, did you remember to also configure the "default" role to remove those specific operations? Remember all users inherit by capabilities of the "default" role. So though the tester role doesn't explicity allow modification of the project area's process, the default role may.

Yes I have removed all access from the default role.
Hierarchy is:
Project
Project Team
Sub Team

Users are added at the sub team level
the default permissions at the Project level are removed (both for |Project & Team)
the roles are defined at the Project level inc Tester (where Tester is also restricted)
Permissions for Default roles are also restricted throughout the whole hierarchy

Regards

When you configured the tester role, did you remember to also configure the "default" role to remove those specific operations? Remember all users inherit by capabilities of the "default" role. So though the tester role doesn't explicity allow modification of the project area's process, the default role may.

Sachin... any update on this??

The ability to modify a jazz process is a process controlled operation, and unless you are a project area administrator or a Jazz.ADMIN (which can override) your user would be governed by their assigned roles. This tells me you still have something misconfigured with your operations. The specific set of operations you need to disable are

Process/Save Project Area/Modify a Project area/*

The only other thing I can think of you may be doing is you are modifying the process template as opposed to the actual process for the project area.

thx Sachin

Ive re-run the test & all is ok now.

As I said before:
Users are added at the sub team level
The default permissions at the Project level are removed (both for Project & Team)
The roles are defined at the Project level inc Tester (where Tester is also restricted)
Permissions for Default roles are also restricted throughout the whole hierarchy

... I think the problem was (& im not 100% sure of this): that the members were added at the sub Team level; members were not added at the Project level. Change: I kept the members @ the sub Team level but also added them @ the Project level ... & it all seems ok now.

Thx for your help.

The ability to modify a jazz process is a process controlled operation, and unless you are a project area administrator or a Jazz.ADMIN (which can override) your user would be governed by their assigned roles. This tells me you still have something misconfigured with your operations. The specific set of operations you need to disable are

Process/Save Project Area/Modify a Project area/*

The only other thing I can think of you may be doing is you are modifying the process template as opposed to the actual process for the project area.