Red Hat Bugzilla – Bug 1261904
[QE] (6.1.z) Boundary event position is not kept relative to the element they are attached to
Last modified: 2015-10-29 01:32:09 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):
Steps to Reproduce:
1. Open attached process, move the large manual task node.
All boundary event will move in the same direction but starting from canvas top-left corner.
Attached boundary events should keep their position relative to the node they are attached to.
Created attachment 1072152 [details]
Created attachment 1072153 [details]
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.
Created attachment 1072338 [details]
process bpmn2 created with latest code in branch
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.
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?
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'.
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?
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.
Hi Jiri, I have added backwards compatibility.
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.
6.2.x commit https://github.com/droolsjbpm/jbpm-designer/commit/5cba6c5b2
Verified in CR1.