Bug 1261904
| Summary: | [QE] (6.1.z) Boundary event position is not kept relative to the element they are attached to | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | Jiri Locker <jlocker> | ||||||||||||
| Component: | jBPM Designer | Assignee: | Tihomir Surdilovic <tsurdilo> | ||||||||||||
| Status: | CLOSED EOL | QA Contact: | Jiri Locker <jlocker> | ||||||||||||
| Severity: | urgent | Docs Contact: | |||||||||||||
| Priority: | urgent | ||||||||||||||
| Version: | 6.1.0 | CC: | alazarot, jlocker, kverlaen, rrajasek | ||||||||||||
| Target Milestone: | CR2 | Keywords: | Regression | ||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | |||||||||||||||
| : | 1263976 (view as bug list) | Environment: | |||||||||||||
| Last Closed: | 2020-03-27 19:13:02 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: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 1259382, 1263976 | ||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 1072152 [details]
Before moving
Created attachment 1072153 [details]
After moving
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. 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. 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? 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. master:https://github.com/droolsjbpm/jbpm-designer/commit/80cc61b9d7bb3bd22707747b584acc01b9b8009a 6.3.x: https://github.com/droolsjbpm/jbpm-designer/commit/7dc7b04a086fc8d6c86db9360fc458527b6442cd 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. Verified in CR1. |
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: