Worklist shows tasks that are not assigned to user

M
Badge +2

Good afternoon,

today i came across something that i had assumed that K2 would take care of. It's quite simple to understand.

I have a form where users request changes to his/her profile. Whenever a request is made, a workflow is started. Such workflow has only one User Event which has a rule to decide which users should be assigned to such request, depending on the type of the user. Everything works fine until the point when I check the Worklist on SharePoint. I had assumed that only the tasks that are assigned to a user would appear on a user's Worklist. If i log, to SharePoint, with two different users (one who should have the task and another that shouldn't have the task) they both have the task.

I checked Workspace to check the Process Overview report to check to whom the task was being assigned to and everything's fine on that department.

Have i forgot a setting somewhere? Has anyone come across such a problem?
Best Regards.

14 replies

S
Userlevel 1
Badge +8

There are a lot of different moving parts your scenario that would need to be checked. You said you were looking at the Process Overveiw report, what about the worklist that is in workspace? Does it behave correctly for each user displaying what is expected?

 

If not, I would review the destination rule settings in the workflow.

 

In SharePoint for two users to be seeing the same worklist and assuming that the destination rule is configured correctly, that tells me that the same user credential is being presented for both users when the form is opened. 

 

How are you testing the different users? If on the same machine, try logging in as one user from one machine and a different user from the other machine to eliminate any session persistance on the workstation.

 

The worklist is security trimmed and if it is planned correctly according to the report then it is something environmental outside of K2.

 

S.

M
Badge +2

Good evening,

Thank you for the help Scott. Unfortunately i'm still having the same problem. I tried going to each user's workspace to check what you said and both had the task assigned, even though only one should've. I re-checked the destination rule of the workflow and even checked the workflow through the "View Flow" option and every user from the specific rule were under the Participants tab of the Action. 

 

I've also checked the permissions for the specific process on Workspace (as admin) and I came across something weird. I re-arranged the permissions for the groups, instead of view i chose View Participate because it makes a lot more sense than having the View permission. After i've done so, the user that should've got the task lost the ability to View Flow because of the permissions. It's starting to become very confusing, both Workflow and Workspace's Reports tell me that the task has been assigned to the correct users when, in reallity, that task was assigned to every user and no one (but admin) can access the Workflow through the View Flow option.

 

I'm accessing the same machine through Remote Desktop for each user, that being said the users i was testing on had their own Remote Access opened and logged with it's own credentials.

Best Regards.

S
Userlevel 1
Badge +8

Can we see a screen shot of the destination rule configuration?

M
Badge +2

Hey, i've attached some screen shots of the Destination Rules of my Workflow and another one showing what i see when i check the Activity's details when i access it through View Flow.

Best Regards.

 

EDIT: Forgot to mention that both groups of users are Security (not Distribution) groups so that they can be used on SharePoint to manage privileges. Not sure if that's a problem.


16185i1CAD30E366712D5C.jpg
11296i34C031EEBE47CE8D.jpg
16750i65F863E84168CD65.jpg
17172i4968F47C0638AA18.jpg
10768i8535DFF14677C251.jpg
S
Userlevel 1
Badge +8

In DR3.png, I see that you have two destination sets defined. What are the rules governing which destination set is used? Because based on what I am seeing so far I would expect both users to see the task.

 

16137i667D54B6ED687D0B.jpg

M
Badge +2

Hey,

I've added a screen shot where you can see the rule i'm using to decide who should get the task. It checks if a value stored as a Data Field (the form sends the value) is 0.

Best Regards.


16099i30B4F488265137E2.jpg
S
Userlevel 1
Badge +8

That is the rule for one of the destination sets, What is the rule for the other? Only one destination set can be evaluated to true at one time. 

M
Badge +2

Hey,

One checks if the Data Field's value is 0, the other one checks if it's different from 0.

Thank You.

S
Userlevel 1
Badge +8

That's good then.

 

I see that you are using groups. Have you changed the membership of the groups or validate the membership of the groups? If you have changed the memberships recently (less than 8 hours) K2 wouldn't have updated the membership yet. Use the Smart Object tester tool and the UMUser smart object to validate your group memberships and also this will cause a refresh to ensure that group memberships cached in K2 are what you are expecting.

 

11976i35CF8F76E1CEE206.png

M
Badge +2

Hey,

I'm not sure if I've changed the group on the last 8 hours. The groups were created some days ago on the AD so it's setup there. I've executed the SmartObject you've talked about and got no results. I've never used nor saw anything about Group Membership, does it have to do with SharePoint? 

I'm not sure if it has anything to do with this but both groups are Security and not Distribution, on the AD.

Best Regards.

S
Userlevel 1
Badge +8

Regardless of where the group lives, the tool should have resolved the membership. If it is a SharePoint group you would have had to use SP: as the security label for the FQN of the group and K2: if it is an AD group.

M
Badge +2

Hey,

I've re-ran the SmartObject's method and it shows me the group with all it's members (screen shot) correctly. I think that when i first ran the method it returned nothing, I might've made a mistake tho.

Best Regards.


12766i0AA6FB35ABE116AC.jpg
S
Userlevel 1
Badge +8

Okay so let's take a moment and focus since there has been a lot of communication on this thread. In your screen shots, you are saying that the users in this view flow are the correct ones. Are they both in one group of the groups in your destination set?  Does the situation you are reporting mean you are logging in with a 3rd user that isn't either one of the two users below?

 

You also mentioned something in a post that is curious:

Quote: I've also checked the permissions for the specific process on Workspace (as admin) and I came across something weird. I re-arranged the permissions for the groups, instead of view i chose View Participate because it makes a lot more sense than having the View permission. After i've done so, the user that should've got the task lost the ability to View Flow because of the permissions. It's starting to become very confusing, both Workflow and Workspace's Reports tell me that the task has been assigned to the correct users when, in reallity, that task was assigned to every user and no one (but admin) can access the Workflow through the View Flow option.

 

At this point I am pretty baffled as to what the issue could be. I would say leave sharepoint alone for a moment and try to validate the basic behavior using workspace to reduce the complexity of the setup. If you are able to validate that tasks are being assigned correctly using the Workspace, then there is something amiss in how things are being surfaced in SharePoint and I would recommend opening a Support Ticket or using Remote Services to help troubleshoot further if it proves to not be a product related issue.

 

14402i9656DBA133501D57.jpg

M
Badge +2

Hey,

The users that are being assigned with the task are the correct ones, they're both from the same group (PedidosDAP). I always have a 3rd user logged as  the user who's requesting the profile change (such user is not in any of the groups). After i request a profile change, I just check both users (one from each group) to check whether or not the tasks were actually assigned as they should (through the worklist). 

 

At the beginning, I had both groups with the Start and View permissions for the process on Workspace. I changed such permissions so that they actually made sense since all users from the groups can only check the instances of the Workflow who are actually assigned to them. After such change was made, everytime i try to view flow with a user who should've got the task assignement (jose.menezes for example) I get prompt with the lack of permissions message. Such event got me thinking about what was actually happening since:

- According to the View Flow, the task was assigned to the correct group.

- The users from the group had the task on their worklist (just like every other user tho).

 

If I remember correctly, if a user has a task assigned to him/her the View Participate permission is enough for what i'm trying to achieve.

 

I've stopped checking SharePoint and started relying on Workspace a lot more since I can also check a user's Worklist on it. I've been around this problem for a while now and re-checked everything a lot of times so I must be missing something since the task still appears on users from different groups.

 

I really appreciate all the help you've been providing on this matter.

Best Regards.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings