+++ 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 2. 3. 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> 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
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)
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.
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.
Maciej Swiderski <swiderski.maciej> 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.
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. @M
Maciej Swiderski <swiderski.maciej> 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? P.S. What version of kie-wb/business-cetral do you use for these tests?
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. master https://github.com/droolsjbpm/jbpm/commit/9c17deaf77a4bbf4cc80595094cc1f9877ba7070 6.0.x https://github.com/droolsjbpm/jbpm/commit/d6ebca4d09536b198937d7619b51e06a253a473b
Verified on ER5.
http://git.app.eng.bos.redhat.com/git/jbossqe/brms.git/commit/?id=330fb1d1cb6de811fdba6853e6d10831647c7e1f