Skip to main content

I'm trying to figure out how K2 determines what items actually show up on the worklist, since it seems to be far more than the list of items that have the logged in user as the destination.


For example, one of our workflows has a superuser as one of the destinations at every step, along with the normal users.  On these users worklist, they see a duplicate of these processes, one which has them as the destination, and another which has the superuser as a destination.  If there are multiple normal users as destinations however, there are still only the two items on the worklist per process (one assigned to them, one to the superuser).


Does anyone know why items are on a worklist, and why specifically there would ever be duplicates like this?  There aren't multiple instances of these processes, it's just that the same instance shows up twice on the worklist somehow.


Any help is appreciated.


Thanks.

The regular users should not ordinarily see the tasks for the super user.  Here are some things to check:



  • Is the super user an AD group or a role?  If the users belong to the same group or role then they will see the tasks.
  • Are you using the default task list filter?  If you created a custom filter, be sure to add a condition like 'ProcessOwner = Me'

 

The super user is a group, but it only has one member.


We are using the default task list filter, and making a custom filter with 'ProcessOwner = Me' doesn't filter anything out.


My latest hunch is that these are all showing up because all the users we are testing with at the moment are K2 Admins, and thus seem to be seeing tasks that don't even have them as a destination, some of which are the duplicates.


Is this normal behavior, that an admin would see so many extra tasks (ones for which they are not a destination), and duplicates of the same task?

That wouldn't be normal behaviour.  Even if users are assigned admin permissions on a process they will not see the processes tasks on their task list unless its been explicitly assigned to them in the activity.


Does this task duplication show up in different K2 worklists (ie both in SharePoint and in the k2 workspace)? 


Although it seems unlikely, is it possible that the super user has their out of office turned on that's delegating to the other users?  Normally you can tell a task is delegated on the default worklist view since the  "original distination" column will show a different user name.


 


 


 


 


 

The duplication shows up on the workspace worklist, the sharepoint worklist, and when I grab the worklist via the API.  It also only seems to affect the first activity.  If the process is moved forward to the next one, the duplication is gone (however if you move it back to the first one, the duplication comes back).


There are no users with out of office turned on currently, so it can't be a shared worklist issue.


The odd thing is that everyone seems to see every destination for the first activity.  When I create a new process, on my worklist I see the item with myself as the original destination, and the superuser as the original destination.  However, everyone else also sees both of those entries.  Once I move the workflow forward to the next activity, I only see the line for myself, and no one else sees anything for that process instances on their workflow.


If I look in the database itself, there doesn't seem to be any entries in the worklist related tables that explain this.  The same two entries appear for every process, regardless of activity.  One row for the superuser, and one row for the current destination.  It's just that everyone can somehow see both rows if the process is on the first step.


I'm just getting more confused the more I dig into this.

Strange.  I can't think of a scenario of how that would occur.


Occasionally I've had to recreate some activities when issues arose that I couldn't figure out the root cause.  Usually that solved the issue or highlighted where I had gone wrong..


 

Well this process is years old.  We have migrated it to blackpearl and this issue just came up there.  All of the settings for the first step are the same for the subsequent ones, so it's very odd.

Check to see if the destination rule has custom code that overrides the default behavior.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings