What does the Client Event option “Allow any user to finish this client event” mean?

2008-02-02T05:56:00Z

A question was posed recently as to what the “Allow any user to finish this client event” checkbox means within a Client Event within K2 process designer within Visual Studio (for K2 blackpearl) and K2.net 2003 Studio.

The purpose of “Allow any user to finish this client event” goes back to at least K2.net 2003 (not sure about before that). In my experience this is a rarely used feature, but can be usefully under the correct business requirements.

By default (which means this is NOT checked for a client event), when a worklist item is attempted to be opened, K2 will validate that the person opening has rights to do so. If this field is checked, anyone with access to the serial number can potentially open it, because K2 will not validate the person opening the task against who it is assigned in the destination rule. The thing to keep in mind, that if this option is checked, you still need a Destination User(s); the task will only appear on the Destination User(s) worklist, emails notifications will only be sent to the destination users; however everyone has the physical ability open and action the task if they know the correct way to access it.

Below is a simplified example…

If we have an activity with a client event with this “Allow any user to finish this client event” option checked that targets John Smith as the destination, and we have email notifications turned on, when the process runs, it will create a worklist item for John Smith (as in it will appear in John’s worklist) and send John an email with the URL to the ASPX page in it. However, John could then forward someone else the email and that other person could click the link and action the item. If this option had not been checked John could certainly forward the email notification to someone, but when clicked that other person clicked the link in the email and opened the page, K2 would compare that person’s credentials against that of the targeted destinations for this worklist item. Since they would not match, K2 would not permit the task to be opened.

As mentioned, this isn’t used too frequently, but I have seen it going back to K2 2003 in certain situations where they wanted to assign a task to a primary user, but let potentially everyone action it (generally because they controlled other aspects of the UI).

Custom Assembly Versioning within a K2 Process

2008-01-14T19:32:00Z

Recently I was asked the below question:

"Let’s say I have a custom assembly that I include in the workflow project. Later, my requirements change and I produce a new version of both the workflow and the assembly. Does blackpearl handle versioning my custom assembly? In other words, workflows using the original assembly can run side-by-side with the new version? "

The short answer is YES, it behaves exactly as described. The long answer is described below to help in better understaning how K2 works:

When you add a reference to a K2 process, the DLL file itself is serialized as binary data to the K2Server database each time you deploy the process. As such this DLL is now associated with this specific process definition version. The first time the process is used, K2 Server extracts all DLLs (K2 generated AND referenced DLLs) to the K2 work folder. This is typically located at:

C:\Program Files\K2 blackpearl\Host Server\Bin\Work

In an example I just worked up, I created a process that referenced a .NET assembly called “MyTestAssembly.dll”. The first time I used this process, it created a folder called:

C:\Program Files\K2 blackpearl\Host Server\Bin\Work\Proc241

NOTE: the number 241 relates to the ID for the process definition version.

If I look in this folder I see the following:

Here you’ll see all the stuff K2 generates as well as my .NET assembly. Don’t be fooled by the date of the .NET assembly… remember it had been serialized to the database as binary data, so when K2 lays it back down on the disk it will always have a new date stamp. If I look at the version info on my DLL I see:

Ok, now I go and change my DLL and rebuild it. As part of the change I changed my DLL version to 1.1.1.1. I then reference in my K2 process and then redeploy. Now if I look at my Work folder I see:

Notice that we now have two folders side by side. ‘Proc241’ was my original version and ‘Proc242’ is the new one. If I browse to Proc242 I see:

This looks pretty much the same as above (Proc241), HOWEVER if I look at the version of my DLL I see the new one:

Thus they should run side-by-side without issue.

Things where handled very similarly within K2.net 2003 so if you are on a legacy project the same knowledge can be applied.

Bob's Blog

What does the Client Event option “Allow any user to finish this client event” mean?

Custom Assembly Versioning within a K2 Process