Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Doubt about permissions envolving project area and team area

Questions
Tags
Users
Badges
LUIZ DE ALMEIDA
(230●1●63●93) edited
Mar 08 '18, 1:45 p.m.

 Hello community,


I would like to know if the following behaviour is the correct in RTC and, if so, why?

The scenario is the following: I have a project area with a team area. In the project area there is a scrum master, John, and in the team area there is a team member, Peter.
The scrum Master has permission to create a story workitem, but team member not.

In the project area there is a category associated to the team area.

In the project area, John creates a story workitem and sets the "filed against" to the project area. Everything is Ok.

Later, Peter (member of the team area) tries to set the "filed against" to his team area, but when he clicks on "Save" the following error is showed: 

Permission Denied. You don't have permission to perform the following actions:
Create a 'Story' work item (create/type/com.ibm.team.apt.workItemType.story).

The workaround to this problem is to set the permission to team member "create the Story workitem". So, here's my doubt: 

Why do I have to set the permisson to "create" the workitem if what Peter is trying to do is to modify an attribute (filed against) that he already has the permission? 

If someone can help me, I will appreciate a lot. If my explanation is not clear, plesase let me know.

Thanks in advance.

1

0 votes

Comments
Donald Nong
Mar 08 '18, 9:12 p.m.

I can see the same symptom in RTC 6.0.5 iFix002. I have the same understanding and am confused as well.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Mar 09 '18, 2:36 a.m.

You don’t explain the membership and roles detailed enough. Since I don’t have the time anyway, here is how permissions work



It is important what role you have in which context and what owns the item to be changed. 

Having said that, I have been wondering about some of the behavior as well, especially create. 

Changing the category and thus changing the owner of the work item might be considered creating the item from the new owners perspective. Owner being the team area.

Donald Nong
Mar 09 '18, 3:40 a.m.

Ralph, the article just doesn't have enough details, particular about team areas. It is interesting to know what permissions are required for just updating the Filed Against attribute. Here is my testing result.
1. Revoke all "Create a work item" and "Modify a work item" for the role "Team Member".
2. Create a team area - all roles inherit permissions from the project area.
3. Add a user to the team area, but not in the project area, and assign the "Team Member" role.

When the user tries to update Filed Against to move the work item out of the team area, the system complains:
Permission Denied. You don't have permission to perform the following actions:
Create a 'Story' work item (create/type/com.ibm.team.apt.workItemType.story)
Modify the work item's subscriptions (modify/subscriptions)
Modify the work item's project area (modify/projectArea)
Modify the work item's 'Filed Against' attribute (modify/category)
Modify the work item's summary (modify/summary)
Remove work item from team area (remove).

When the user tries to update the Filed Against to move the work item into the team area, the system complains:
Permission Denied. You don't have permission to perform the following actions:
Create a 'Story' work item (create/type/com.ibm.team.apt.workItemType.story)
Modify the work item's subscriptions (modify/subscriptions)
Modify the work item's project area (modify/projectArea)
Modify the work item's 'Filed Against' attribute (modify/category)
Modify the work item's summary (modify/summary).

Even "project area" and summary are considered being modified. It is hard to explain.


1 answer
2,927 views
0 votes

One answer

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (63.9k●3●36●48) edited
Mar 09 '18, 6:32 a.m.

 Please run the runtime report for the user in the Eclipseclient on that project area.

For all I know the user Peter has the everyone role for the story incoming to the team area ( in the context of the team area). He only has the team member role in the project area. If the team area overrides the permission settings, then the user needs a role in that team area.

As far as I can tell, there is no role inheritance and the user has only the role everyone/default for objects filed against the team area. I think that is explained in the article I sent. I can not really check es my internet connection is bad. I don’t do this often enough, to know it for sure, but I am fairly certain nonetheless.

If you want Peter to be team member in the team area, then you have to add Peter to the team area and assign the team member role there.

Please check the article and make sure to understand what role the users have where and what process areas govern the permission for an object/own it.

In any case read the article https://jazz.net/library/article/291 and save a link to it for further use.

0 votes

Comments
LUIZ DE ALMEIDA
Mar 09 '18, 8:38 a.m.

Hi Ralph, thanks for you contribution. But let me try to explain better...


Peter is a team member only in the team area and he has not the "Everyone" role.
The "Team member" role has not the permission to "create the story", but to modify the "Filed Against" attribute.

The problem is that when Peter tries to change the "Filed Against" to a category associated to the team area he is part of, he cannot change.

You said an important thing previously..."Changing the category and thus changing the owner of the work item might be considered creating the item from the new owners perspective. Owner being the team area." If it's true, so this is the explanation to this behaviour.

My question is "why does Peter need the permission to create if what he is doing is changing an attribute"? This seems to be an incorrect behaviour to me. What do you think?
Since now, thanks you so much.

Veronica Alvarado
Oct 25 '18, 7:29 p.m.

Hi everybody,

I have the same question about this behavior.

I have two team area associated to their categories, Development team with member and developer role, and Testing team with member and tester role.

In my formal process, a developer role must not create a Defect and only Tester role has permission to create it. However to allow a developer to assign a defect to a different team and owner, it is necessary that developer role has permissions to create defects; causing our process to fail and creating defects for no valid reason.

Can you help to explain if there is any way to follow our formal process and allow assign defects between different team areas?

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,019
× 102
× 32

Question asked: Mar 08 '18, 1:40 p.m.

Question was seen: 2,927 times

Last updated: Oct 25 '18, 7:29 p.m.

Confirmation Cancel Confirm