It's all about the answers!

Ask a question

Work Item approvals, change state

sam detweiler (12.5k6195201) | asked Jan 16 '14, 11:59 a.m.

is this sentence about approvals

"Work item customization can be used to automatically trigger a state transition on the work item if an approval has been accepted (or rejected)."

what does that mean? create a script to change the state? I don't see how the 'state' field in the list of approvals ever gets enabled. 

Accepted answer

permanent link
Stephanie Bagot (2.1k1513) | answered Jan 16 '14, 1:09 p.m.
  1. In your eclipse client, open up the project area.
  2. Navigate to the Process Configuration tab.
  3. Navigate to Team Configuration -> Event Handling
  4. 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.
However, Event handlers aren't included OOB and are contributed using extensions via and The first is the extension point to define events and the second is use to contribute handlers for the given events.
sam detweiler selected this answer as the correct answer

sam detweiler commented Jan 16 '14, 1:29 p.m.

fabulous, thanks for the great detail. 

a place I haven't created any extensions!!.. fun!

I 'assume' that the workitem Save pre/post conditions fire before these events.. 

sam detweiler commented Jan 16 '14, 3:37 p.m.

well, this seems to need a little more data. 

is there a wiki someplace on this? 
I continue to have trouble tying the pieces together. 

sam detweiler commented Jan 21 '14, 4:48 p.m.

is there any wiki doc on this?  I 'think' the description is upside down (based on the content of the plugin.xml)

assuming rtc provides the definition, I should only have to create the event handler. 

Ralph Schoon commented Jan 27 '14, 5:45 a.m.

There is no documentation I am aware of. I found examples looking at the extension point in the SDK.

sam detweiler commented Jan 27 '14, 6:09 a.m.

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..

Ralph Schoon commented Jan 27 '14, 8:15 a.m.

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).

sam detweiler commented Jan 27 '14, 7:18 p.m.

 ok, i have approvals added to workitems.. how do you change the state? marked 'pending', but the 'edit approval' button is greyed out' .

I do not have workflow actions assigned at this time. 

sam detweiler commented Jan 28 '14, 5:48 a.m.

hm.. I logon as the assigned user and I can edit.. as long as it is not ME the workitem creator.

showing 5 of 8 show 3 more comments

One other answer

permanent link
Susan Hanson (1.6k2201194) | answered Jan 16 '14, 10:36 p.m.
Under Project Configuration -> Configuration Data -> Work Items -> Approval Trackings
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.

sam detweiler commented Jan 16 '14, 11:08 p.m. | edited Jan 16 '14, 11:09 p.m.

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.

Susan Hanson commented Jan 17 '14, 12:29 a.m.

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.

Ralph Schoon commented Jan 17 '14, 3:04 a.m.

sam detweiler commented Jan 17 '14, 6:09 a.m. | edited Jan 17 '14, 6:24 a.m.

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?

Ralph Schoon commented Jan 17 '14, 6:43 a.m. | edited Jan 17 '14, 7:08 a.m.

Sam, hard to answer the question.

  1. The Built in solution (OOTB) Susan talks about is something the Work Item component handles itself.
  2. The extension to 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
  3. 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.

sam detweiler commented Jan 17 '14, 7:09 a.m.
  1. I like, someone other than the programmer decides what to do ON Approval or Rejection..
  2. the participant fires on every save, of every workitem.

  3. 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

sam detweiler commented Jan 17 '14, 10:27 a.m.

 Ok, once again I see this crazy error which isn't clear on the cause

WARN eam.repository.provision.internal.ProvisionService  - CRJZS0383E The "Create_Workitem_Approvals" bundle could not be resolved.

I copied an existing ini file to modify
I used cut/paste the folder and feature names into the ini file.

what is 'bundle'? that is the 'ID' in the feature 

and the plugin filename is

Ralph Schoon commented Jan 17 '14, 10:47 a.m.

I think it is whatever you call the feature when packaging it. I follow the Extension Workshop pattern.

showing 5 of 8 show 3 more comments

Your answer

Register or to post 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.