Bug 1261904 - [QE] (6.1.z) Boundary event position is not kept relative to the element they are attached to
[QE] (6.1.z) Boundary event position is not kept relative to the element they...
Status: VERIFIED
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Designer (Show other bugs)
6.1.0
Unspecified Unspecified
urgent Severity urgent
: CR2
: ---
Assigned To: Tihomir Surdilovic
Jiri Locker
: Regression
Depends On:
Blocks: 1259382 1263976
  Show dependency treegraph
 
Reported: 2015-09-10 08:12 EDT by Jiri Locker
Modified: 2015-10-29 01:32 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1263976 (view as bug list)
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 with boundary events (30.93 KB, application/xml)
2015-09-10 08:12 EDT, Jiri Locker
no flags Details
Before moving (67.32 KB, image/png)
2015-09-10 08:16 EDT, Jiri Locker
no flags Details
After moving (84.71 KB, image/png)
2015-09-10 08:16 EDT, Jiri Locker
no flags Details
process bpmn2 created with latest code in branch (34.65 KB, application/xml)
2015-09-10 15:04 EDT, Tihomir Surdilovic
no flags Details
Diff after re-attaching all boundary events (16.42 KB, text/plain)
2015-09-11 12:13 EDT, Jiri Locker
no flags Details

  None (edit)
Description Jiri Locker 2015-09-10 08:12:48 EDT
Created attachment 1072139 [details]
Process with boundary events

Description of problem:
I have a process that has catching intermediate event (aka boundary event) attached to a node (e.g. task, subprocess). When I move the "attached-to" node for [X,Y] pixels, boundary event position is reset to [X,Y] relative to canvas top-left corner.

Version-Release number of selected component (if applicable):
6.1.3.CR{1,2}

How reproducible:
-

Steps to Reproduce:
1. Open attached process, move the large manual task node.

Actual results:
All boundary event will move in the same direction but starting from canvas top-left corner.

Expected results:
Attached boundary events should keep their position relative to the node they are attached to.

Additional info:
Comment 1 Jiri Locker 2015-09-10 08:16:33 EDT
Created attachment 1072152 [details]
Before moving
Comment 2 Jiri Locker 2015-09-10 08:16:50 EDT
Created attachment 1072153 [details]
After moving
Comment 4 Tihomir Surdilovic 2015-09-10 15:03:46 EDT
Did you generate this BPMN2 with older Designer version by chance? What happens after import the boundary events seem to not be associated with the task. If you re-position the boundary events back into the task (slightly move them back into boundary until it lights up green and drop them) the move and move after save of the task works fine. 

I have attached the bpmn2 of the exact same task created with whats latest in that branch and it works after import or reopen as well so maybe please try with that and let me know what you find.

Thanks.
Comment 5 Tihomir Surdilovic 2015-09-10 15:04:45 EDT
Created attachment 1072338 [details]
process bpmn2 created with latest code in branch
Comment 6 Jiri Locker 2015-09-11 09:33:49 EDT
Tiho, I can confirm that what you have described is an applicable workaround. I think it is important to let customers know that this patch is affected by this known issue and advise them not to move nodes with attached boundary events unless they reattach them first.
Comment 7 Kris Verlaenen 2015-09-11 10:54:02 EDT
Jiri,

Do you know how you ended up with a detached boundary event?  I guess if boundary events could get detached, that might be an issue.  It might of course be that this was the result of some other issue that is already fixed, so it might no longer be possible to end up with a detached boundary event in the latest version?
Comment 8 Jiri Locker 2015-09-11 12:13:30 EDT
Created attachment 1072606 [details]
Diff after re-attaching all boundary events

Oh, I see I haven't mentioned the process was created in Designer 6.1.2 (the previous patch). And the same issue can be observed with processes created in older releases (don't know which exactly at the moment).

I have applied the workaround in 6.1.3 (re-attached all boundary events according to Tiho's guideline) saved the process and made a diff between the original 6.1.2 process and 6.1.3 process with re-attached boundary events. Please take a look at it, it may be helpful in identifying the issue. I can see 3 types of changes:

1. Added CDATA sections (related to newline support in node metadata.
2. Changes in color attributes.
3. And finally new attribute 'drools:dockerinfo'.
Comment 9 Tihomir Surdilovic 2015-09-14 14:26:21 EDT
1. Should not affect this
2. Should not affect this
3. added for BZ 1196259 

I don't think that we can provide backwards compat for this because it would revert 1196259 and would go back to incorrect bpmn2 generated. If possible please lets add this in docs for customers. WDYT?
Comment 10 Jiri Locker 2015-09-16 11:49:00 EDT
Hi Tiho, thanks for linking the related bugzilla.

From QE perspective it is a bug and some kind of backward compatibility is probably needed to fix this. We want to avoid having to tell customers something like:
- open all of your processes, find all boundary events and reattach them,
- run this migration script that will generate correct dockerinfo attributes,
- or make sure not to move nodes with boundary events.

If you are sure it is impossible to fix this without reverting bz 1196259, close this bz as WONTFIX and we will make sure it is included in release notes as a known issue.
Comment 14 Jiri Locker 2015-09-17 04:43:54 EDT
Brilliant! Thank you, Tiho.

One more thing: this ticket is related to the next 6.1.x release, which is based on 6.2.x community branch, so please cherry-pick there, too.
Comment 15 Tihomir Surdilovic 2015-09-17 05:54:42 EDT
6.2.x commit https://github.com/droolsjbpm/jbpm-designer/commit/5cba6c5b2
Comment 16 Jiri Locker 2015-10-12 11:15:02 EDT
Verified in CR1.

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