It's all about the answers!

Ask a question

Permission Denied creating a work item from Participant


Michael Tunnicliffe (2634) | asked Jul 29 '11, 12:36 p.m.
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



permanent link
Eduardo Bello (4401922) | answered Jul 29 '11, 2:31 p.m.
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?


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:



IContributorHandle handle = // Get here the IContributorHandle of the user with the required permissions

IImpersonationService impersonationService = getService(IImpersonationService.class);

try {
impersonationService.runAs(handle ,
new IImpersonationService.ImpersonationRunnable() {
public void run() throws Exception {
try {
// Your code goes in here
} catch (Exception e) {
// Watch your exceptions
}
}
});
} catch (ExecutionException e) {
throw new TeamRepositoryException(e);
}


permanent link
Michael Tunnicliffe (2634) | answered Aug 02 '11, 5:44 a.m.
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.

permanent link
Geoffrey Clemm (30.1k33035) | 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
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?

permanent link
Michael Tunnicliffe (2634) | answered Aug 03 '11, 6:15 a.m.
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


Register or to post your answer.