Work Item approvals, change state
Accepted answer
- In your eclipse client, open up the project area.
- Navigate to the Process Configuration tab.
- Navigate to Team Configuration -> Event Handling
-
At the bottom of the view, see Work items -> Work Item State Changed Event.
This is where the event to change a state can be configured by a certain action, such as work item approval. Essentially this means when you approve a work item, it will change the work item state. This is similar to operation behaviour where an action is executed based on a configured 'kick off' action.
Comments
fabulous, thanks for the great detail.
well, this seems to need a little more data.
is there any wiki doc on this? I 'think' the description is upside down (based on the content of the plugin.xml)
There is no documentation I am aware of. I found examples looking at the extension point in the SDK.
thanks.. I have made progress. both my event handler and reworking your sample.
I don't think event handler is worth it.. events only by teamarea?
I don't think your participant sample can work as is.. as it says it requires client libs.
and a question: state IS a workitem.. FULL.. so, shouldn't u be able to get a workitemcopy directly and not have to load the workitem AGAIN?
ProcessArea and ProjectArea are the same handle..
I spent way too much time trying to make it load on 3.x.. but it uses a 4.x only api..
Sam, if there is client API in the sample, remove the plugin and try common or service. It should not be in there, I might have to review the code and upload a fixed version.
In the participant, you get some access to the work item initially e.g. for reading data.
You might be able to manipulate that directly or might have to resolve it again (if you get stale data exceptions when saving).
ok, i have approvals added to workitems.. how do you change the state? marked 'pending', but the 'edit approval' button is greyed out' .
hm.. I logon as the assigned user and I can edit.. as long as it is not ME the workitem creator.
One other answer
you can select the Workflow and then for the approval type, specify a workflow action.
So for us, on our Defect Workflow, we state that an Approval of type "Verification" when marked Approved triggers the Workflow Action "Verify" and if the approval of type "Verification" is marked Rejected, it triggers WorkflowAction "Reject".
Perhaps this is not what you were looking for, since it doesn't require any extension.
Susan
Comments
thank you.. we would do the same.
how do you create the approvals, which drive this next part of the workflow.
my users would like those created automatically.
on the transition to verifying state create a Verification approval, which when approved triggers the action, which moves the defect to Verified state.
so the extension was to inject the verification approval on the start verifying state change.
they like the idea of the approvals, just don't want to have to do two things instead of one.
move to verifying state AND create a verification approval.
there-in lies the rub :-)
We haven't found any way to tell RTC to create an approval record, so our process states that the developer must create the approval record and THEN deliver the code and put it into "Ready" state (they can do this in 1 step by Deliver and Resolve, or 2 actions Deliver and then change state). Then our testers know to look for things in Ready, they go get the level that the problem is fixed in, test it, and if the problem is fixed, they Accept their record, if not, they Reject. When they Reject and click Save, RTC then changes the work item state. We do get cases where the developer "Forgets" to create the approval, and then the tester goes and creates it for themselves.
I have on my "to do" list to write a saveParticipant that could check on the state movement to Ready if there is an approval of type Verification in Ready state, and if not, create one. But I haven't written that part yet.
Susan
You might want to look at this post: https://rsjazz.wordpress.com/2012/11/30/a-create-approval-work-item-save-participant/
thanks Ralph. that didn't show in any searches I did for approvals info.
just for commentary, that will get fired on every workitem save, vs the other extension point only on state transitions.. right?
Sam, hard to answer the question.
- The Built in solution (OOTB) Susan talks about is something the Work Item component handles itself.
- The extension to com.ibm.team.process.service.eventHandlers would trigger on any qualified event and you would then do whatever you want. I think it is asynchronous however and I am not sure I would take that approach
-
The participant from my blog triggers on any qualifying event as well, which would be a work item save. It runs after the save (but can prevent the commit). You could also use this approach to find approvals that are approved now and, I think, use it to do a state change. However, it would show up in the history as two events - because you would do an active save.
- I like, someone other than the programmer decides what to do ON Approval or Rejection..
- the participant fires on every save, of every workitem.
operationId="com.ibm.team.workitem.operation.workItemSave">
- may trigger the runtime on every repository action (already happening) and get called on whatever major 'event' (subclass of all events) its filtered to respond to.
1 does not CREATE approvals
Ok, once again I see this crazy error which isn't clear on the cause
I think it is whatever you call the feature when packaging it. I follow the Extension Workshop pattern.