Animation continues upon rolling back SubGraphCollapsed transaction

GoJS
1

I’ve added a DiagramListener that prompts the user with a confirm window upon expanding/collapsing a subgraph. If the user hits ‘cancel’, the undoManager will rollback the transaction, but it looks like the animation will still occur.

On the other hand, when you expand the subgraph, if the user hits ‘cancel’, the animation will not occur.

Would this be a bug, or an intended feature that rolling back the transaction doesn’t stop the animation?
Also, I am able to stop the animation in 1.6 beta4 by including animationManager.stopAnimation(), but not in beta3.

Here’s a codepen:

2

We’ll investigate this. Thanks for reporting the problem or inconsistency.

3

I see what you mean. There does seem to be an animation issue here that we will investigate, but I do not recommend you try to rollback this transaction.

Even without animation, you would be rolling back a transaction that will still (internally) call diagram.commitTransaction afterwards, which results in a warning if you’re using the go-debug.js version:

“Ending transaction without having started a transaction: Collapse SubGraph”

It would be better if you made your own button that asked the user, and only conditionally began the action based on their answer, instead of trying to rollback this particular transaction.

See this page for an intro on buttons and see buttons.js file for definitions of all the buttons built-into GoJS. You’d want to make a custom SubGraphExpanderButton.

4

Thanks Walter, Simon.

Is there a good way to create a function to pre-emptively a̶s̶k̶ ̶f̶o̶r̶ ̶p̶e̶r̶m̶i̶s̶s̶i̶o̶n̶ do something before every transaction?

As I understand it, DiagramListeners and EventListeners can only interject while or after an event/action has been taken.

5

Well, to back up a bit (or rollback), what do you want to accomplish with every transaction, generally?

If you want to stop users from doing certain things at certain times in a broad sense, there may be easier ways, see for instance all the options in the Permissions intro page. Or you can always modify/override the “can…” methods from CommandHandler (see the Commands intro page).

6

The permissions within the web application will not be the single source of truth of what is allowed or not allowed.

What I’m trying to do is inject a function before every action in order to ask a backend if that action is allowed. For example, if I want to drag Chevrolet into a European Car Group, I would want call the backend first, which might deny the action, because Chevrolet is not an European Car.

The rules can be changed in the backend - say an European company acquires General Motors. Now Chevrolet might qualify as a European Car. The backend would now allow the action to be taken.

Rule changing would happen pretty often, and it would be easiest to only have to update one ruleset.