-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto Placement should not put elements on top of existing flows #757
Comments
Thanks for reporting this issue. From the alternatives you've provided I'd personally go with: Expected Behavior
|
Hi! Unfortunately I found a new major problem in this particular bug which is not anymore just an UX problem. |
Yea, that is indeed an issue. A different one though. |
How would you address this from the UI side of things? |
The auto placement stuff works if the task has no out sequence flow. In that case it cannot be a problem because it will be sure that only one out sequence flow will be placed. But If a task has an out sequence flow in that case program should fall back to user side to manually drop the task. |
We cannot go with this option, as it is not gonna be understandable for the user. However, I consider changing the drop on flow behavior to remove duplicate incoming and outgoing connections (as I cannot figure out a scenario where these would make sense). |
Multiple outcoming sequence flows can be at start gateways. |
Or do not take it intolerant its just an option but please consider also to drop this kind of auto placement stuff and revert back to that method where user decided manually where to put the task in the flow. |
Did you try dragging out elements from the context menu? It achieves exactly what you mentioned:
|
A small visualization regarding my previous comment:
As you can see, there are certain cases where sequence flows are not equivalent (i.e. because they are default or have conditions assigned). There are other cases though where it makes absolutely no sense to keep these (scenario two). From the BPMN prespective this would otherwise be equivalent to a AND gateway. |
As mentioned, I believe both issues should be tackled / investigated separately. I've opened #774 for the sequence flow duplication issue. |
I did not know about it. Thanks for pointing it out. |
So I guess we can close this issue? |
It is still a problem that the automatic placement render the task on the sequence flow (like it was merged) and hard to see what is happening. |
Additional feedback we got convinced me that this is an actual issue. We'll improve auto-placement to ensure elements are not being dropped on incoming or outgoing sequence flows. |
Parts of this issue, namely the duplication of sequence flows got addressed via #774. |
I've updated the issue description to reflect the work left to close this issue. |
This is part of refactoring actions (as it applies mostly to the "modify" phase of the developer/modeler job journey). |
The auto placement feature may place elements on top of existing sequence flows:
We should circumvent this issue, as this particular situation is hard to grasp for users.
Tasks
Original Bug Report:
Hi!
I am using bpmn-js version 0.26.4.
When I want to create a new inner element from the previous element context pad (which already has an output sequence flow line), if there is enough space to the element creation but there is already an sequence flow line placed, it creates the element on the sequence flow line which is annoying and can lead to hardly interpretable and visible business flow.
Expected Behavior
Actual Behavior
Newly created element placed on the sequence flow line.
Steps to reproduce the Behavior
See
![element_auto_placement](https://user-images.githubusercontent.com/9417960/35516687-b86d0278-050c-11e8-865e-2a08889cf72b.gif)
The text was updated successfully, but these errors were encountered: