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

Permission error when trying to approve a Parent work item that i linked to a child work item in a different project area

Questions
Tags
Users
Badges
nannette Mori
(50●3●9●85) Dec 14 '15, 5:43 p.m.

User belongs to Project A where the parent work item lives.  In order to approve this item using the "approval" action in the approval tab. 

All the children that live in a different project area must be resolved before the  Parent work item can be approved. We do have the post -operation "All children Resolved" enabled.

The user performing the approval only belongs to the project area where the parent lives, he cannot be a member where the child work items live because it contains proprietary information. 

The error we are getting is:

Permission denied.  Permission denied during "All children resoveved" CRJAZ1316E the user does not have permission to read items that have the work item access type:

Is there a way we either script it or through an extension for the approval to occur without being a member of the project area where the child work items exist and be able to keep the "All Children Resolved" post operation enabled.

Currently I had to disable the "All Children Resolved" post operation so the user could approve the DR.

Thank you for your assistance.

1

0 votes

Comments
sam detweiler
Dec 14 '15, 5:46 p.m.
I think you could set the permissions on the parent project to 'anyone', course that is pretty sketchy

2 answers
6,094 views
0 votes

2 answers

Permanent link
Luis Peregrina
JAZZ DEVELOPER (181●1●4) Dec 15 '15, 3:29 p.m.
It seems we are hitting a design issue because the check is done at server-level and always using the authorization level from the currently logged user. If you all agree this should be changed, an RFE (Request for Enhancement) should be created.

0 votes

Comments
sam detweiler
Dec 15 '15, 4:53 p.m.
I don't think this is a design issue at all. if the work request  (approve workitem) is initiated from outside the server (some client), then the userid of that client should be used for all requests. if the request comes from INSIDE the server (some async task, etc) then it should use that userid assigned to that process. you should never be able to 'promote' yourself to a higher level authority. this is why I said that you could make the parent project open to all to update. or add the specific users to the access list, under the project access control.

Luis Peregrina
JAZZ DEVELOPER Dec 16 '15, 10:51 a.m.
In this case is the user that requests the change, no?

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Dec 16 '15, 10:57 a.m.
This is the user that approves, as the state check is likely triggered as result of this. An approval does not change the state, unless you have configured the approval workflow.

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (64.6k●3●36●49) Dec 16 '15, 2:40 a.m.
As the user has no read permissions in the project area where the child work items live and the advisor runs in the context of the user that issues the command by design, the permission issue can not be avoided.

There is no real good solution to this problem. The advisor can not read the child links, thus it can not decide.

I suspect you also set up the approval workflow so when approving, the parent tries to transition to a closed state, which then triggers the second advisor that fails.

If you can't give the approvers read permission to the child work items, consider to remove the automatic close and assign users that have sufficient permissions to close approved work items.

0 votes

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

Question asked: Dec 14 '15, 5:43 p.m.

Question was seen: 6,094 times

Last updated: Dec 16 '15, 10:57 a.m.

Confirmation Cancel Confirm