Bug 1261904 - [QE] (6.1.z) Boundary event position is not kept relative to the element they are attached to
Summary: [QE] (6.1.z) Boundary event position is not kept relative to the element they...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Designer
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: CR2
: ---
Assignee: Tihomir Surdilovic
QA Contact: Jiri Locker
URL:
Whiteboard:
Depends On:
Blocks: 1259382 1263976
TreeView+ depends on / blocked
 
Reported: 2015-09-10 12:12 UTC by Jiri Locker
Modified: 2020-03-27 19:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1263976 (view as bug list)
Environment:
Last Closed: 2020-03-27 19:13:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Process with boundary events (30.93 KB, application/xml)
2015-09-10 12:12 UTC, Jiri Locker
no flags Details
Before moving (67.32 KB, image/png)
2015-09-10 12:16 UTC, Jiri Locker
no flags Details
After moving (84.71 KB, image/png)
2015-09-10 12:16 UTC, Jiri Locker
no flags Details
process bpmn2 created with latest code in branch (34.65 KB, application/xml)
2015-09-10 19:04 UTC, Tihomir Surdilovic
no flags Details
Diff after re-attaching all boundary events (16.42 KB, text/plain)
2015-09-11 16:13 UTC, Jiri Locker
no flags Details

Description Jiri Locker 2015-09-10 12:12:48 UTC
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 12:16:33 UTC
Created attachment 1072152 [details]
Before moving

Comment 2 Jiri Locker 2015-09-10 12:16:50 UTC
Created attachment 1072153 [details]
After moving

Comment 4 Tihomir Surdilovic 2015-09-10 19:03:46 UTC
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 19:04:45 UTC
Created attachment 1072338 [details]
process bpmn2 created with latest code in branch

Comment 6 Jiri Locker 2015-09-11 13:33:49 UTC
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 14:54:02 UTC
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 16:13:30 UTC
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 18:26:21 UTC
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 15:49:00 UTC
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 08:43:54 UTC
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 09:54:42 UTC
6.2.x commit https://github.com/droolsjbpm/jbpm-designer/commit/5cba6c5b2

Comment 16 Jiri Locker 2015-10-12 15:15:02 UTC
Verified in CR1.


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