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
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.
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.
In this case is the user that requests the change, no?
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.
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
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