Bug 1264028 - Task list displays task to original user even after automatic reassignment
Task list displays task to original user even after automatic reassignment
Status: VERIFIED
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.2.0
Unspecified Unspecified
urgent Severity urgent
: ER4
: 6.2.0
Assigned To: Maciej Swiderski
Jan Hrcek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-17 07:02 EDT by Jan Hrcek
Modified: 2015-10-14 11:35 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Process definition to reproduce the issue (12.14 KB, application/xml)
2015-09-17 07:02 EDT, Jan Hrcek
no flags Details
Error when original user works with reassigned task (42.83 KB, image/png)
2015-09-17 07:03 EDT, Jan Hrcek
no flags Details
Reassigned human task in data sets (103.18 KB, image/png)
2015-09-17 07:04 EDT, Jan Hrcek
no flags Details

  None (edit)
Description Jan Hrcek 2015-09-17 07:02:56 EDT
Created attachment 1074399 [details]
Process definition to reproduce the issue

Description of problem:
This is a regression.
It is possible to define reassignment for human task in process definition.
For given human task this specifies timeout and user, to which the task should be reassigned, if it is not started/completed before timeout (See process definition attached, that can be used to reproduce the issue)

How it worked (correctly) before: after reassignment occured, task list no longer showed the task to the original user, instead it was shown to the user we reassigned to.

How it works now (bug): after the reassignment occurs, taks list still displays task to the original user (who no longer has access to the task, because it was reassigned to another user - and as a results sees Exception modals when he tries to manipulate with the reassigned task) and is not displayed in the task list of the  reassignment user.


Version-Release number of selected component (if applicable):
latest 6.3.x snapshot

How reproducible:
Always

Steps to Reproduce:
1. Create new process in designer and import BPMN2 definition from the attachment, Build & deploy the project
2. Start the instance of the given process, entering original and reassignment users in process start form. The proc. definition is flexible, so you can define initial user for assignment (initialAssignment variable) as well as the user to which the task will be reassigned after 10 seconds after process started (reassignTo variable).
3. Check task list with both original user and with reassign user.

Actual results:
THe task is present in the tasklist of the original user forever. But when he clicks release or anything, he gets an Exception modal "no current status match"

The task never appears in the task list of the user to which the task was reassigned

Expected results:
This worked correctly in 6.1.

Additional info:
Attaching screenshot of the error as well as a record from HUMAN_TASKS_WITH_USERS dataset, showing the task after reassignment occurs.
Comment 1 Jan Hrcek 2015-09-17 07:03:51 EDT
Created attachment 1074400 [details]
Error when original user works with reassigned task
Comment 2 Jan Hrcek 2015-09-17 07:04:15 EDT
Created attachment 1074401 [details]
Reassigned human task in data sets
Comment 3 Maciej Swiderski 2015-09-30 09:25:52 EDT
fixed by introducing new event listener methods that are called on reassignment so audit task table is updated and by that will allow queries to return proper results.

jbpm
master:
https://github.com/droolsjbpm/jbpm/commit/7510393ffbfc7579aa90bead8767965c6bbe56c1

6.3.x:
https://github.com/droolsjbpm/jbpm/commit/a1baf8525ccf5af46b36b3fbfc320dbf81d47918
Comment 4 Jan Hrcek 2015-10-14 11:35:25 EDT
Cool, now it works as before. Verified with BPM Suite 6.2.0 ER4.

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