Permission error when trying to approve a Parent work item that i linked to a child work item in a different project area
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. |
2 answers
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 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.
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.
|
|
Ralph Schoon (62.0k●3●36●43)
| 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. |
Comments
I think you could set the permissions on the parent project to 'anyone', course that is pretty sketchy