Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1288171

Summary: RuntimeDataServiceImpl. getProcessInstanceHistory returning incorrect active nodes for tasks inside ad-hoc subprocesses
Product: [Retired] JBoss BPMS Platform 6 Reporter: Tihomir Surdilovic <tsurdilo>
Component: jBPM CoreAssignee: Maciej Swiderski <mswiders>
Status: CLOSED NOTABUG QA Contact: Radovan Synek <rsynek>
Severity: medium Docs Contact:
Priority: high    
Version: 6.3.0CC: kverlaen
Target Milestone: DR1   
Target Release: 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-29 14:23:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sample bpmn2 process none

Description Tihomir Surdilovic 2015-12-03 18:12:20 UTC 
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 18:13:42 UTC 
Created attachment 1101880 [details]
sample bpmn2 process
Comment 3 Maciej Swiderski 2015-12-07 16:40:55 UTC 
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

jbpm
master:
https://github.com/droolsjbpm/jbpm/commit/b071ece6847c40e0d180cb775cdb7b06daafb7db
Comment 4 Radovan Synek 2016-03-29 14:23:29 UTC 
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.