Can I add a user to a team role without adding them to a project area role?
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 |
2 answers
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 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 ;-) 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. These might be of interest as well. you have to understand this to understand how permissions and operational behavior work.
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".
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. So you share a common process.
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. 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.
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
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.
Comments
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 ?
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?
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.