I want to, after a model has been loaded in the modeler, lock the modeler from user changes (disable user modeling), and also being able to unlock (re-enable user modeling).
In effect, that would be the equivalent to first using Modeler and then user Viewer, and Modeler again - but without having to import the XML every time I lock/unlock.
Disabling modeling actions can occur while having the context-pad and/or popup-menu activated (the menu should be re-rendered or disappear).
My three alternatives I’ve come up
Swapping Modeler with Viewer (not preferred)
Unloading/loading modeling modules, i.e. “destroy” but for specific modules only
Modeling modules can be disabled by a flag/event
I would be happy to provide a PR with any code required to support my use case, but I would appreciate advise on the design and how to best fit the bpmn-js/diagram-js architecture.
Swapping requires the diagram to load again --> requires canvas/svg to unload and load another. The user will experience a “flickering” for smaller diagrams and a loading icon for larger diagrams.
The viewer does not support the same type of navigation as the modeler.
I want to user to see a “locked modeler”, i.e. still displaying the palette creates this visual effect (my example hides locked actions, but I’m also considering to gray them out to enhance the effect).
In my use case we have multiple users that could potentially work with the same diagram.
On the long term we would like to support live editing by replicating modeling actions over web sockets.
On the short term, when user A modifies the same diagram that user B is looking at, user B will receive a notification there is a newer version to download, locking the modeler.
Also, if user B makes changes virtually simultaneously, but after A, a concurrency conflict occurs and user B should still be able to see the changes he made as a way of helping him to replicate the same change on the new version (can open a new tab with new version and visually compare the two).
Also, if user B makes changes virtually simultaneously, but after A, a concurrency conflict occurs and user B should still be able to see the changes he made as a way of helping him to replicate the same change on the new version (can open a new tab with new version and visually compare the two).
The stuff I am always wondering is, why users should have that restriction, as the stuff mentioned in your comment can practically always happen.
You’re right.
Locking the modeler is a temporary solution for us until we have implemented “live editing”. And there is no need for you to support our work-around.
I will abandon my open pull requests and we will implement the feature in a custom build by overriding the relevant modules/functions.
However, some functions can’t be overridden easily, so I will return with a pull request in a couple of weeks that would make necessary changes to make the remaining functions overridable.
Just wanted to let you know we solved it without any modifications to diagram-js or bpmn-js, but rather adding a module that is hacking a bit on the other modules…
Not really a pretty solution, but at least concentrated to one file so it can easily be removed once we don’t need it any longer.