+++ This bug was initially created as a clone of Bug #1261904 +++

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

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:

— Additional comment from Jiri Locker on 2015-09-10 14:16:33 CEST —

— Additional comment from Jiri Locker on 2015-09-10 14:16:50 CEST —

— Additional comment from JBoss Product and Program Management on 2015-09-10 14:20:06 CEST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

— Additional comment from Tihomir Surdilovic on 2015-09-10 21:03:46 CEST —

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.

— Additional comment from Tihomir Surdilovic on 2015-09-10 21:04:45 CEST —

— Additional comment from Jiri Locker on 2015-09-11 15:33:49 CEST —

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.

— Additional comment from Kris Verlaenen on 2015-09-11 16:54:02 CEST —

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?

— Additional comment from Jiri Locker on 2015-09-11 18:13:30 CEST —

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'.

— Additional comment from Tihomir Surdilovic on 2015-09-14 20:26:21 CEST —

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?

— Additional comment from Jiri Locker on 2015-09-16 17:49:00 CEST —

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.

— Additional comment from Tihomir Surdilovic on 2015-09-16 20:11:46 CEST —

Hi Jiri, I have added backwards compatibility.

master:https://github.com/droolsjbpm/jbpm-designer/commit/80cc61b9d7bb3bd22707747b584acc01b9b8009a

6.3.x: https://github.com/droolsjbpm/jbpm-designer/commit/7dc7b04a086fc8d6c86db9360fc458527b6442cd

— Additional comment from Jiri Locker on 2015-09-17 10:38:22 CEST —

Fixing release flags. This bz is targeted for the next 6.1.x roll-up patch.

— Additional comment from JBoss Product and Program Management on 2015-09-17 10:40:06 CEST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

— Additional comment from Jiri Locker on 2015-09-17 10:43:54 CEST —

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.