Gantt - adding a task creates two transactions in the state manager

[chrisb]

Hey Guys,

This seems like a bug.
When you add a task to the gantt, with the STM enabled and recording you initially get one transaction, with a create, and update.

Then, when the response from the server comes back with the server generated id, another transaction is added with the task id being updated from the phantom id to the server generated id.

What this means, is that if someone wants to undo the add task, they need to press undo twice, the first one seemingly doing nothing.

Should the id update be encapsulated within the original transaction? Or is there any way to ignore the id update from the STM? Do I need to disable recording after adding a record? When would I re-enable recording?

Thanks for any help

Chris.

[chrisb]

This also creates a further issue, as once the phantom id -> generated id is undone, when you press undo again to remove the task, when the store does the synchronization, it tries to delete via the phantom id, which also seems to be a bug.

[arcady]

Yes it's not supported at the moment. It's told in the docs here: https://bryntum.com/docs/gantt/#Core/data/stm/StateTrackingManager

Note: STM currently does not support undoing server side added and saved records. Therefore it's recommended to reset the queue each time a tracked store(s) loads from or saves its changes to the server.

That's why we reset the STM queue right after load or sync response comes (we do that in our php demo):

        gantt.project.on({
            load       : me.onAfterLoadSync,
            sync       : me.onAfterLoadSync,
            ...
            thisObj    : me
        });
...
    onAfterLoadSync() {
        // since we load all the stores data from the server
        // we reset undo/redo queue (it no longer makes sense)
        this.stm.disable();
        this.stm.resetQueue();
        this.stm.enable();
    }
...

That helps us not thinking of such use cases
So we recommend you to use that approach as well.

And I'll make a ticket for this request so far: https://github.com/bryntum/support/issues/3266

[chrisb]

Hey arcady,

This would essentially make undo unworkable for us, as we save after every change. Is there anything you can suggest as a workaround? Possibly some way we could intercept the undo, and combine the two of them? Or adjust the state manager transaction list?

Thanks

Chris

[arcady]

I would start with overriding StateTrackingManager onModelUpdate method. It's called to register a record update operation in the queue. Out of the box it looks like this:

    onModelUpdate(model, newData, oldData) {
        stateTransition(this, this.state.onModelUpdate, model, newData, oldData);
    }

So here I would just ignore some id related changes so they would not appear in the undo queue (need also to handle references, for example a phantom resource gets a new identifier which causes resource field change on the corresponding assignment model etc).

That looks a bit tricky but doable.