Bug 1288171 - RuntimeDataServiceImpl. getProcessInstanceHistory returning incorrect active nodes for tasks inside ad-hoc subprocesses
RuntimeDataServiceImpl. getProcessInstanceHistory returning incorrect active ...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
high Severity medium
: DR1
: 6.3.0
Assigned To: Maciej Swiderski
Radovan Synek
Depends On:
  Show dependency treegraph
Reported: 2015-12-03 13:12 EST by Tihomir Surdilovic
Modified: 2016-03-29 10:23 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-29 10:23:29 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)
sample bpmn2 process (14.23 KB, application/xml)
2015-12-03 13:13 EST, Tihomir Surdilovic
no flags Details

  None (edit)
Description Tihomir Surdilovic 2015-12-03 13:12:20 EST
Description of problem:

Example process with user tasks inside ad-hoc subprocess. When starting process instance and viewing the process view, the active tasks are not highlighted. What is highlighted is the ad-hoc process itself. (example here: http://imgur.com/F1xgjTl)

jBPM Designer is getting passed the ID of the ad-hoc subprocess instead of the task inside the subprocess.

The console code should be getting node info from getProcessInstanceHistory in RuntimeDataServiceImpl and there seems to be some issue there with the executed queries

How reproducible:

Steps to Reproduce:
1. In workbench create sample process (bpmn2 attached)
2.Build Project
3. Start process instance
4. View Process View

Actual results:
The "active" node is the ad-hoc subprocess

Expected results:
The "active" node should be the task inside subprocess
Comment 1 Tihomir Surdilovic 2015-12-03 13:13 EST
Created attachment 1101880 [details]
sample bpmn2 process
Comment 3 Maciej Swiderski 2015-12-07 11:40:55 EST
added test case to illustrate it does work as expected, so moving to modified to double check - main thing here is that ad hoc subprocess does not activate any tasks in it so these must be explicitly signaled to be active

Comment 4 Radovan Synek 2016-03-29 10:23:29 EDT
Works as Maciej described. If the problem is not connected with not signalling the task inside the ad hoc subprocess, feel free to reopen the issues.

@Maciej Thanks for enhancing the test coverage.

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