Bug 997139 - Auto assigning tasks to same actor when they are part of a swimlane
Auto assigning tasks to same actor when they are part of a swimlane
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
high Severity high
: ER5
: 6.0.0
Assigned To: Maciej Swiderski
Marek Baluch
Depends On: 874548
  Show dependency treegraph
Reported: 2013-08-14 14:29 EDT by Alessandro Lazarotti
Modified: 2014-08-06 16:08 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 874548
Last Closed: 2014-08-06 16:08:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPM-3848 Critical Resolved Auto assigning tasks to same actor when they are part of a swimlane. 2018-06-04 11:39 EDT

  None (edit)
Description Alessandro Lazarotti 2013-08-14 14:29:51 EDT
+++ This bug was initially created as a clone of Bug #874548 +++

Description of problem:
Platform issue for https://issues.jboss.org/browse/JBPM-3848

How reproducible:
Design a process with a lane and 2 human tasks inside it. Both of it are assigned to the group.

Steps to Reproduce:
1. Claim the first task and complete it
Actual results:
Next task not auto-assigned, needs to be claimed again from the group tasks

Expected results:
Next task should be auto-assigned, and show up in "Personal Tasks" list.

--- Additional comment from JBoss JIRA Server on 2012-11-23 08:04:09 EST ---

Maciej Swiderski <swiderski.maciej@gmail.com> updated the status of jira JBPM-3848 to Resolved

--- Additional comment from Mauricio Salatino on 2013-06-24 10:50:04 EDT ---

Fixed in master, as jira says

--- Additional comment from Alessandro Lazarotti on 2013-08-14 14:26:38 EDT ---

As it was fixed only for BPMS6 (until now), I am setting this one to ASSIGNED again. I will clone the issue to BPMS6
Comment 2 Marek Baluch 2013-09-19 10:46:59 EDT
Verified on ER3.

This obviously works may be event too good :). Before I close as VERIFIED I have a couple of questions.

1) Should the reassignment be made if 'mary' who completed the first task is not listed in the 'actors' list?
2) Should the reassignment to user 'mary' be made even though she is not part of a 'user group' specified in the task? (this is probably a bit extreme as a Lane should target a specific group)
Comment 3 aparna.natarajan 2013-09-20 06:25:04 EDT
As a user who wants this, these would be my answers:

1) As long as  'mary' is a part of the group to which the task is assigned its fine, she needn't be in the 'actors' list.
2) No the next task should not be assigned to 'mary' if she is not the part of the group.
Comment 4 Marek Baluch 2013-09-20 07:08:50 EDT
Aparna - Thanks for clarification!

Reopening this BZ because the current implementation does not behave as specified above.

Currently reassignment is made every time. It does not matter weather a user belongs to a group or not. I tried 2 more cases besides the happy path.

Using user 'mary' which does not belong to a group.
1) assign to mary if a group on task is not specified and mary is not in the actors list.
 - This will succeed. Based on the comment above this should be fine because the task does not define a specific user group. Do you agree?

2) assign to mary if a group on task is specified but mary does not belong to this group
 - This will succeed too. Based on the above is not correct.
Comment 5 JBoss JIRA Server 2013-09-20 07:19:51 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3848

guys, I think the whole point of using lanes is to directly associate tasks with same group of actors that might work on this issue. Making the tasks on same swim lane to have different assignments (groups or actors) is sort of against the concept of using swim lanes. So I am not quite sure it really makes sense to have such support. The biggest issue is that process is not aware of the actual group membership and thus trusts the swimlane context that brings in the information about next user to own the task.
Comment 6 Marek Baluch 2013-09-20 07:23:33 EDT
Hi Maciej,

your point is exactly why I used the word extreme in https://bugzilla.redhat.com/show_bug.cgi?id=997139#c2. If the customer agrees then we can still move the issue to VERIFIED.

Comment 7 JBoss JIRA Server 2013-09-23 07:19:47 EDT
Maciej Swiderski <swiderski.maciej@gmail.com> made a comment on jira JBPM-3848

I could not reproduce the problem. When given (katy) user claimed the first task the second one has already been assigned to the same user and placed in REserved state.

Attaching process that is slightly modified version of the original (replaced admin group with HR to avoid conflicts between group and user admin/admin which will cause issues)

Thomas, would you mind giving it a try again with attached process?

What version of kie-wb/business-cetral do you use for these tests?
Comment 8 Maciej Swiderski 2013-10-02 05:46:01 EDT
The reason why user was able to claim task (based on swimlane context) even though (s)he was not part of potential owners is due to the left over of the previous support for swim lane that when actor was found in swim lane context it was set as ActorId explicitly on work item and thus making that user immediately as potential owner. Fixed this to not set swim lane actor as the actual actor and thus in case of attempt to claim such task claim will be rejected and the task will be left in Ready state for claim by any of the potential owners.


Comment 12 Marek Baluch 2013-12-10 04:41:44 EST
Verified on ER5.

Note You need to log in before you can comment on or make changes to this bug.