It's all about the answers!

Ask a question

How to restrict permission to access project area and sprint planning in RTC?


jane zhou (106865) | asked Jan 04 '18, 11:26 p.m.
retagged Jan 09 '18, 10:17 a.m. by Ken Tessier (84117)

  Hi Someone who may concern,


        Our management team wantS to make a team has the following permission:
1 be able to "view only" the defects in the project, but not task/ story/epic...
2 "no access" to see details in sprint planning and project area 

         However, I found RTC can not be configured that way. As long as a user is added into the project, they can see project area configuration page and planning page by default , which can not be controlled by permission section.

         So, we are wondering  how we can use other ways to meet the needs above?

         Thanks!

Best Regards,
Jane Zhou    

2 answers



permanent link
Ken Tessier (84117) | answered Jan 09 '18, 10:15 a.m.

In addition to the links that Ralph provided, this tutorial does a good job of providing an overview of the various access control mechanisms:  Control access to project areas and their artifacts.


Ken 


permanent link
Ralph Schoon (63.1k33646) | answered Jan 05 '18, 10:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jan 05 '18, 10:57 a.m.

There is no simple/automated solution for that as far as I can tell. RTC is for collaboration and not for preventing it.

You can find a small description of what you can do with RTC 6.x here: https://rsjazz.wordpress.com/2016/01/27/manage-access-control-permissions-for-work-items-and-versionables/ section The Rules – Work Items.

  1. You can limit access on project area level. This is on a general level, not per work item type. You can use one project area for the defects and another one for the rest and manage the visibility that way
  2. You can use categories to limit access to work items by the team areas associated to the category. Setting the category is done by hand and is not work item type specific.
  3. You can use access groups - this is again not automated and not type dependent

I think the solution I would look into is number 3 with a follow up action setting/clearing the access context to the desired access group value if needed (creation, type change, type is now a defect or the type is changed away from defect) in a follow up action. E.g. clear the access context for defects so anyone has access. The way access groups work should prevent the not privileged users also from type changes.

The API's involved are described in https://rsjazz.wordpress.com/2016/01/27/manage-access-control-permissions-for-work-items-and-versionables/ and the related posts.  

Please note that the user can still look at plans, queries, reports etc. but they run with their read access so they would only be ale to see the data for the work items they are allowed to see. E.g. queries/plans for the externals would only show defects because they are not member of the access groups needed to look at the other work items.

Category based access control (item 2) works a bit different than what users expect. A follow up action as described above could also be created.

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.