Skip to main content

We've noticed an issue where users (members of a K2 Role) are seeing errors when clicking a task notification link after another one of the assigned role members has already claimed the task. 

 

As a result, they are receiving the error attached, which indicates that the worklist item could not be opened for their user name.

 

This is, obviously, expected but we want to find a more descriptive error to show when this happens.  We wanted to be able to retrieve the currently assigned/claiming user and redirect them elsewhere.  Is this possible?  There doesn't seem to be a way of accessing the participant of a task using just the serial number. 

 

K2 SmartForms: 1.0.7

K2 Blackpearl: 4.6.8


12379i5D21050EEEC637EF.jpg

Hi Marvin

 

One way to approach this is to add an "If an error occurred" statement to your Form Initialize rule.

 

This statement will trap any error during the rule execution. You can target specific errors by adding an advanced condition together with the error statement. In the advanced condition you can inspect the Error object in the System Values.

 

For example, the condition "Error Message contains 24411" will trap the error you are currently getting. You can see that error code in the error message you are getting now.  Another error code you may see when the task is completed is 26030. 

 

After trapping the error you can display a friendly message and redirect the user.

 

Have a look at the screen shots for an example of this.

 

 

 

 


12966i075BDE137EA5264C.png
12868iB46DEF35A1A89617.png

Andrew,

 

Thank you very much!  That's about as far as I had gotten so far.  I had been able to wire up the advanced condition to catch the 26030 and 24411 errors and display a "user friendly" error and redirect to a worklist. 

 

Is there any way to retrieve the currently assigned user or the user who has claimed the task?  This is the one piece I was having a lot of trouble figuring out.  I'd like to be able to display the user who claimed the task when a task is assigned to a role so that users can know where the tasks have gone.

 

Thanks again!


Hi Marvin

 

I have struggled with this in the past. There are a couple of SmartObjects that will return this data, such as "Activity Instance Destination" (Look Under Workflow Reports -> Workflow General)  however the problem with them is that the returned data appears to be restricted according to your process rights.  I think you can get around this by granting all users "View" process rights. Another challenge that this SmartObject does not accept the Serial Number as an input. You need to parse it out into its components - the first part is the Process Instance ID and the second is the Activity Instance Destination ID.

 

The other option is to look at the K2 Web services,. You can create a SmartObject with this (register a new Endpoints WebService Service Instance)  and there is an OpenWorklistItem method that accepts the Serial Number. I haven't had much luck with this however as calling these SmartObject methods from a SmartForm as I get different permission issues depending on the Authentication mode.

 

http://help.k2.com/onlinehelp/k2blackpearl/DevRef/4.6.9/default.htm#Web_Services.html

 

 

 

 

 


Marvin

 

Just a suggestion, but you can also configure your task so that you don't get the situation where the task is opened by one user but not completed, and other users get the error message when they try and open the task.

 

If you change the destination users rule to create a slot for each destination, a different Serial Number will be created for each participant. This will mean that if multiple people are assigned the task they will all get a different serial number. One user opening the task (and not completing) will not stop another from opening.

 

You need to be careful though to change your succeeding rule so that you still complete the activity when at least one user completes their task.


Hi,

 

I remember making use of the Activity Instance Destination Reporting SmartObject before to get serial numbers and who it is assigned to.

A serial number is made up of the ProcessInstanceID_ActivityInstanceDestinationID which are both in the Activity Instance Destination SmartObject.

 

I would take the SerialNumber parameter, split it on the underscore and then use the first value as the Process Instance ID input and the second as the Activity Instance Destination ID input.

This would then return who has the task among other things.

 

One careful thing to note is that you will need to grant all users View rights on your process otherwise this call will fail.

 

I hope this helps!

 

Regards,

JohanL


I'm looking at the data in that SmartObject but am seeing no discernable way of detecting who the claiming user is.  If I use both the Process Instance ID and Activity Instance Destination ID, I get my own line which just has an Active status. 

 

If I search for just the Process Instance ID, I can retrieve the list of all assigned users, which was promising.  However, even though the other user had already claimed the task, it still showed both of our status(es) as "Active".   Is there something I'm missing here? 

 

My destination plan is All at Once which is how we want it to be.  The task is assigned to a role with 1 or more users and the first person in that role that claims the task has sole rights to that task (unless they release it, of course) until they action it.


Hi,

 

Would you mind posting some screenshots?

It should work if you are passing the process ID.

 

Also make sure you are looking at the Activity Instance Destination Smartobject under the Workflow Reports > Workflow General section.

Also ensure you have full view rights on the process and not just View Participate.

 

Thank you,

JohanL

 


Hi Marvin

 

It appears that the Activity Instance Destination SmartObject will return a status, but that this does not reflect if the worklist item is open or not. This status will show Active, Completed or Expired.

 

I'm not sure what else you can do in terms of trying to find the user when the status is "Open". My suggestion as per my earlier post would be to allocate a slot to each user so that you don't encounter this issue.


Reply