-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Inconsistent redo behaviour when recreating the first participant in the model #1439
Comments
I have noticed that my library version is outdated, however the bug is still present in the newest version (8.3.1) |
Hi, Thank you for reporting this. I was able to reproduce the issue. Indeed, it seems unreasonable that we re-generate the Process id. I suspect that the bug may have something to do with the CreateParticipantBehavior. We will happily accept a pull request with a fix. If you want to implement that, I will support you if you get stuck. |
Hi, Thank you for the reply and confirmation. Unfortunately, I am still quite a javascript newbie, and even more so a newbie to the bpmn-js library, so I am worried that I would do more harm than good by trying to fix it (I have taken a look around the file and I am not quite sure what might be causing the behaviour, unfortunately). If this issue will still be open in the future when I gradually gain more insight, I might gladly give it a go :). |
That's OK :) Reporting a valid issue is already a great contribution. |
* during pre-execute phase of elements.create process is passed to shape.create to be reused during execute phase (there is no execute phase for elements.create) * process must be reused during execute phase for undo and redo to work * refactor implementation Closes #1439
* during `#preExecute` of `elements.create` process is passed to `shape.create` to be reused during `#execute` (there is no `#exeute` for `elements.create` as it only executes other commands during `#preExecute`) * process must be reused during `#execute` of `shape.create` for `#redo` to work * refactor implementation Closes #1439
* during `#preExecute` of `elements.create` process is passed to `shape.create` to be reused during `#execute` (there is no `#exeute` for `elements.create` as it only executes other commands during `#preExecute`) * process must be reused during `#execute` of `shape.create` for `#redo` to work * refactor implementation Closes #1439
* during `#preExecute` of `elements.create` process is passed to `shape.create` to be reused during `#execute` (there is no `#exeute` for `elements.create` as it only executes other commands during `#preExecute`) * process must be reused during `#execute` of `shape.create` for `#redo` to work * refactor implementation Closes #1439
* during `#preExecute` of `elements.create` process is passed to `shape.create` to be reused during `#execute` (there is no `#exeute` for `elements.create` as it only executes other commands during `#preExecute`) * process must be reused during `#execute` of `shape.create` for `#redo` to work * refactor implementation Closes #1439
Describe the Bug
When adding a first participant/pool into the model, the ID of the process element does not change. If I undo this action, the participant gets removed and the ID of the process still stays the same as expected. However, when I redo this undo (re-add the participant), the id of the process is different this time.
Note: note sure if this is also a bug, but when I remove the participant via delete (removing the only participant in the model), the id of the process also changes.
Steps to Reproduce
Expected Behavior
I would have expected the redo action to bring the model into the same state as before, not modifying the id of the process.
I would have also expected the "id transfer" to work both ways. The process id is typically kept the same when the first participant is added (except for the mentioned edge case). This is however not the case when removing the last participant in the model using the delete functionality (not an undo), as the id of the process changes.
Environment
The text was updated successfully, but these errors were encountered: