Permission Denied creating a work item from Participant
I have a Participant plugin that runs on workItemSave and detects the change of a field within the work item, and depending on some conditions will create a new work item in a different Project Area.
Unfortunately, the user that makes the original change to the work item field does not have permissions on the Project Area (this is an important requirement to prevent the user being able to read updates that go into the new work item once it has been created). Is there an API available to temporarily escalate the privileges of the Participant (for example to a task user with the required permissions) just for the purposes of creating this work item? |
4 answers
I have a Participant plugin that runs on workItemSave and detects the change of a field within the work item, and depending on some conditions will create a new work item in a different Project Area. You could check com.ibm.team.repository.service.IImpersonationService. It allows you to run some code as another contributor. I didn't use it yet, but think it should be something like this:
|
I tried using this yesterday and I receive an auth error saying that JazzAdmin authority is required. There is no stack trace in the ccm.log and the web UI just reports "Work Item save failed"; only the Eclipse UI shows the JazzAdmin message.
The javadoc for the method states that admin privileges are required to use it. So, unfortunately, it looks like this method is no good for escalating privileges. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 02 '11, 9:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The only approach I am aware of to handle the case where the
out-of-the-box permissions don't give you the granularity you want is to give the user the permissions they need to perform this operation, and then to add your own operation Participant that aborts the operation if the user tries to do one of the things you don't want them to do. Cheers, Geoff On 7/29/2011 12:38 PM, tunniclm wrote: I have a Participant plugin that runs on workItemSave and detects the |
I'm not sure if it is possible to use that approach.
1) Trying to use regular permissions: Can you configure the Project Area so that a person can create a work item (Project Area -> Permissions) but not read it (Project Area -> Access Control)? 2) Granting more permissions than you want to give and denying those you don't want the user to have in a Participant/server-side plugin: The only operation you can attach to (as far as I know) is workItemSave, so I don't know how I could use this approach to prevent the person from reading a work item. Is what I'm trying to do possible in a server side plugin? The other ideas I thought of are not that attractive: 1) Have the participant create a dummy work item, or set a flag or similar in an area they can write to. Have a client plugin (logging in with a privileged account) poll the repository to check this flag and create a work item in the restricted area. 2) Have the participant create a work item in a shared area that both the original user and the target users (those who will actually use the work item) can access, and then have the target user somehow move that work item into their restricted project area (I'm not sure about this, I heard that you can move work items like this; I don't know if this will enforce the access control that I want though). Any help appreciated! |
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.