Management.WorklistItem.Users

  • 12 March 2010
  • 4 replies
  • 1 view

Badge +5

The problem: Get the user or users who have a worklist item claimed.


In K2 2003, this was simple - call GetWorkListItems in the Management API, filter the items to ones with Status of Open, then return the Destination property of the items.


K2 blackpearl makes this more complex due to the introduction of Roles. Destination may contain a Role name. We need to know what user(s) in that Role actually have the item open.


The Class Library Reference for SourceCode.Workflow.Management on help.k2.com doesn't even list the WorklistItem.Users property. Through the Visual Studio debugger and some testing, I found that it appears to contain a collection of WorklistUser objects with Status and UserName properties. These users seem to correspond to the users in the Role.



  • Are my assumptions correct?
  • Will WorklistItem.Users ever be null?
  • Will the user Status accurately reflect Open vs. Allocated, etc.?
  • If no Role is used, will Users be empty, will it contain a single user with the UserName identical to the item Destination, will it be null, or something else?
  • Is there a better way to accomplish this task?

Thank you!


4 replies

Badge +9

I tend to go straight to the DB to get who has what work items assigned to them - In the K2Server database, slot has that information (status) and you can join from slot up to tables that have data that makes more sense (like _WorklistHeader).  Let me know if you need more details

Badge +5

My understanding was that directly accessing the transaction database can void your support contract. K2serverLog is the only one we're permitted to read directly.

Badge +9

I'm pretty sure it is ok to read the database, just not manipulate the data within.  If there is a way to get at it through the API, then of course that is the best approach, I just prefer the flexibility of going straight to the source data

Badge +5

I'm pretty sure it's not, with the exception of the log database. See Ockert's response on this thread .

Reply