It's all about the answers!

Ask a question

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


0
1
nannette Mori (50572) | asked 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.


Comments
sam detweiler commented 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



permanent link
Ralph Schoon (63.1k33645) | answered Dec 16 '15, 2:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.

permanent link
Luis Peregrina (18114) | answered Dec 15 '15, 3:29 p.m.
JAZZ DEVELOPER
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.

Comments
sam detweiler commented 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 commented Dec 16 '15, 10:51 a.m.
JAZZ DEVELOPER

In this case is the user that requests the change, no?


Ralph Schoon commented Dec 16 '15, 10:57 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

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.