Skip to main content

Hi

I have a requirement to develop a Custom Worklist WebPart. One of the many requirements is for a certain group of users (G1) to have a full view of the current status of a worklistitem. This means when a G1 user submits the form to the next Actvity in the process (which G1 user has no involvement in as the task will be performed by another group (G2) or an Activity containing a Server Event) the worklist item should remain in G1 worklist with an updated status, as well as appearing G2 worklist for actioning and task completion. The requirement is that G1's worklist to now show the item's status as being with G2 and any other subequent Activities in the process. This is not a parallel processing requirement where G1 users continue to be involved in data capture, the steps are sequential by nature, but there is a requirement for G1 users to perform a completing task at the end based on the success of the intermediate steps in the process. If this approach is possible which areas of the K2 API should I be looking at for its development.

Thanks in advance

Andrew

Have you seen this?


http://k2underground.com/k2/ProjectHome.aspx?ProjectID=66


 


I can think of a couple of ways to accomplish this since you are building a custom worklist.

1. Impersonation

 SourceCode.Workflow.Client API, which is the API you are already using for WorklistItem interaction, has an Impersonate method on the Connection object.  However, the right to impersonate other users must be granted to individual identities within the Workspace > Management > Workflow Server > ServerRights.

You could first create the Workflow.Client connection as the logged in G1 user to get the tasks actually assigned to the G1 user (as per normal).  Then you could close that connection and programatically create a new connection under the identity (via a K2 connection string) that has impersonate rights.  THen invoke the Impersonate() method to impersonate a G2 user.  You can then invoke OpenWorklist method (being sure to use WorklistCriteria object to filter appropriately if need be). 

At this point you would then need to merge the two results sets in order to display.

FYI, the K2 Developer's Reference contains info on how to impersonate at the following location:

   Users > Impersonation > Using User Rights Impersonation

2.  Utilize the Management API to retrieve the other worklist items

You could first create the Workflow.Client connection as the logged in
G1 user to get the tasks actually assigned to the G1 user (as per
normal). Then use SourceCode.Workflow.Management, which requires K2 server admin rights to use (even programmatically), to get back specific worklist items.  Note, you will not have access to Data Fields via this API.

You'd then need to merge the results to bind to UI.

The K2 Developer's Reference has some assistance on this one too: 

   Processes > Accessing > How to access and return information from the
Global Worklist

3. Utilize the Out of the Box Reporting SmartObjects

You could first create the Workflow.Client connection as the logged
in
G1 user to get the tasks actually assigned to the G1 user (as per
normal). Then call the appropriate SmartObject wrapper to the reporting data based upon what information you're looking for.

You'd then need to merge the results to bind to UI.

For some more info on how to programmatically interact with ootb reporting SmartObjects:

   http://k2underground.com/blogs/fromthebench/archive/2008/06/02/how-to-retrieve-process-instance-reporting-data.aspx

 

HTH


Reply