Is there a way to use "Accept" Assigned Activity in the underlying workflow?

[kpritchard]

To illustrate use case - we've added states to Change Task lifecycle to differentiate between work that is assigned but not yet started ("Assigned") and work that is underway ("In Work"). (sidebar - if/when Project-Link supports Revisions we'll do same for Project-Link based Work Items!). What I'm wondering is if there is a way to use the "Accept" button in a user's Home Page? As an example -user gets the "do something" Change Task Assigned Activity and the Change Task is at an "Assigned" State, when the user"Accepts" the Assigned Activity the Change TaskState isset to "In Work". Ultimately I'm hoping to use this differentiation as an aide to Team Leads in managing resources and workloads.The setState is dead easy, I know... Method robot. I'm thinking that upstream of that is a conditional with listener to act as a gate. What I need to know is if there is something to listen for (when something get's "Accepted") and if so what that is, and if anyone has done anything like this?

[MikeLockwood]

We have the same issue. The only thing we've been able to figure out so far is to actually add two separate assignments in critical places - one that says "I'm accepting and starting work on this" and one to say "I'm done with the work.

The Accept action is on the Work Item and is reportable but disappears when the Work Items are deleted via queue. If you choose to override the default and not delete completed work items, there may be some way to report on it. But - There is no visual indication in the user's Assignments that any assignment has in fact been Accepted, and no real way to tell.

[ericstarkman]

Hi Keir,



A few ideas to consider, in increasing order of difficulty...



1) Have you considered changing the concept of "Accept" to instead be two
different workflow activities? Activity #1 ("please accept this work") goes
to multiple people... first one who wants to "accept" it actually
*completes* it... then we set state on the PBO, and then the person who
completed Activity #1 gets Activity #2 ("ok now *do* this work")...



2) Create a custom task template for this specific case, with a custom
"Accept" button, which runs your code to do the actual accept
(WorkflowHelper.service.acceptAssignment) & set state on the PBO.



3) Can try to catch it via a listener service (this may be the most work to
build and test, and may impact performance if you have a busy system)...

3.1) Listed on UPDATE event to wt.workflow.work.WorkItem to catch the
updates

3.2) Filter to identify accept events (notable because Status has been set
to WfAssignmentState.ACCEPTED)

3.3) Checks to make sure it is coming from a workflow activity where we want
this behavior (a property file with a list of applicable activity names
could be used),

3.4) Finds the PBO associated with that workflow,

3.5) Makes sure it is in the expected state (again - property file),

3.6) Sets state to the desired state (again - property file).



-Eric