It's all about the answers!

Ask a question

Can I add a user to a team role without adding them to a project area role?


Richard Good (872158) | asked Sep 28 '15, 7:45 a.m.

I would imagine this question has been asked before, and I have searched the forum. We only want users in a particular team to be able to work on components owned by their streams in their team areas and on categories associated with their team areas. I imagined this could be achieved by simply adding them to the appropriate team area, but this seems to deny them any access.

What sort of access do I need to give these people at project area level or what might I be doing wrong in regard to the team area role?

Note the process model being used is a variant of the standard formal process model.

Thanks

Richard 


Comments
Geoffrey Clemm commented Sep 29 '15, 12:43 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

In RTC, the ways in which read-access is controlled is quite different from the ways in which write-access is controlled.  For example, the process model and your role is irrelevant for read-access control, while they are very relevant for write-access control.   So to confirm, you are looking for write-access control ?


Richard Good commented Sep 29 '15, 3:47 a.m.

I need to strictly control read access to project areas, I think I can avoid controlling read access within project areas, so my comment on Norman's answer may be misleading, just developing an access control twitch! I imagine you are referring to the access control tab on the project area in regard to read access?


Geoffrey Clemm commented Sep 29 '15, 11:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

It's still unclear whether you are asking a question about read access control, or write access control.   If it is about read access control, then the answer will vary depending on the specific type of artifact to which you want to control read access (for example, the details of read access control are different between work items, workspaces, components, and files), so you will need to specify the type of artifact you are interested in.   For write access control, it is a combination of: repository permission, licensing, permission, and operation behavior, with the details of permission and operation behavior defined in the articles referenced in earlier answers.

2 answers



permanent link
Norman Dignard (356688167) | answered Sep 28 '15, 10:24 a.m.

A few things we noted on this:

RTC - users only in a team cannot create streams. Need to be a project level.

DNG - team inheratence does not fully work. IBM has noted this in 502 and there is an RFE to get DNG "team aware".

RQM - some team permisions not being followed down properly - Users in a team can save a review but can't modify it.


Comments
Richard Good commented Sep 28 '15, 10:31 a.m.

Thanks Norman, I am dealing with just RTC in this case, but no doubt I will deal with lifecycle projects in due course..

The solution appears to be to add all team members as developers to the project area, but then I need to make sure I remember to add all roles to the team areas otherwise access will inherit down. Need to be careful with access rights at this particular organisation so would prefer to start allocating user not admin access at team level - this may not be possible. 


permanent link
Arun K Sriramaiah (3.2k13177) | answered Sep 28 '15, 7:55 a.m.
Hi Richard,

Please find the links below.

http://www-01.ibm.com/support/docview.wss?uid=swg21647158

https://jazz.net/library/article/1075#com.ibm.team.process.definitions.server.componentPermissions

https://jazz.net/forum/questions/39622/restricting-access-to-a-stream

Please let me know do you still need any further information.

Regards,
Arun.

Comments
Richard Good commented Sep 28 '15, 8:12 a.m.

I like the second link, some things I didn't know there.

Really after a specific answer in regard to the project area to team area inheritance - don't understand how it is working and would like to, none of the articles help me with that specific issue, don't think the pre conditions are it either, feel free to correct me, I'm missing something ;-) 


Richard Good commented Sep 28 '15, 8:19 a.m. | edited Sep 28 '15, 8:23 a.m.

Note we use a master project and inherit its process model to the project area / team area I'm having issues with. The access control of the project area looks right, but it might be being ignored?

It is implied that any role granting read access of some sort to the project area controlling the team area will allow me to have what I want in my inherited from other project area scenario, still not ideal.


Ralph Schoon commented Sep 28 '15, 8:28 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

These might be of interest as well. you have to understand this to understand how permissions and operational behavior work.




Richard Good commented Sep 28 '15, 9:42 a.m.

Thanks these articles are also helpful especially for new administrators. I have a couple of web pages with useful articles these days. However, still can't see why the access rights at master project level cannot be modified at team area level without putting the guys in a project area role on the derived project area, looks as though it should work. Note that the default permissions on our master project are mostly switched off, is there a minimum set that enables this to work.  If we put all users in the developer role on the derived project then the problem goes away.


Ralph Schoon commented Sep 28 '15, 9:47 a.m. | edited Sep 28 '15, 9:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I don't understand "Master Project".

You can have users only entered as a member of the team area. You just have to understand that this user will only have the default role "Everyone" related to objects owned by the project area and other team areas. This means he can only perform operations allowed to "Everyone".  

This is why I posted the links to how permissions and roles work.


Richard Good commented Sep 29 '15, 3:54 a.m.

The process model is housed on a "Master Project" at this organisation, all Project Areas used for real work are derived from this project (use the Master Project's process model) such that we can swap any changes in more easily.

Sorry if I'm unclear.  looked through the various permissions on the Master Project and could not see which permissions I needed to change such that the Everyone default user had read access to see the team areas, but not much else, imagined this couldn't be done for a project area that used another project area's process model, happy to be told otherwise/ be proved wrong.  I'll have another look.


Ralph Schoon commented Sep 29 '15, 4:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

So you share a common process.

The read access restriction is still derived from the setting in the specific project area and not derived from the project area that shares its process. Actually that one must be accessible by everyone.





Richard Good commented Sep 29 '15, 12:59 p.m.

 Yes that would work, but so should the Members of the project area hierarchy option I have chosen, well the message above indicates that anyway. I'm pretty sure I don't want to specify everyone as its important that derived project areas are not visible to the general RTC database users by default. The question is what does "If this project area shares its process anyone who can read a project area that uses the process will be able to read this project area, regardless of the settings on this page" mean? You would imagine that adding someone as a member of a team in a project area would grant them the required read access to the project area. This isn't a major problem by the way, just can't see why simply adding users to team areas doesn't work. Thanks for your replies.


Ralph Schoon commented Sep 29 '15, 2:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The project area sharing the process needs to be public, so the process area that shares the process can read it. The project area that shares the process has no data that needs to be protected and you can make sure using roles that only members of that project area - which are its admins or customizers - can modify the process.

Other answers indicate what the rules and sometimes probems are. In general you can add users just to team areas, keeping in mind how permissions and operational behavior works.


Richard Good commented Sep 30 '15, 1:01 p.m.

 Setting the project area that shares the process "read only access" to "everyone" does seem to solve the problem - thanks. Apologies if I am being thick, but we have to be very sure that we don't some how dole out read only access to all project areas by doing that, that sort of thing can get me shot ;-) 

showing 5 of 10 show 5 more comments

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.