support gantt e calendar

[cds_cds_eb]

Sometimes when i click in new Task, the undo button counts as two actions, i found some topics about it from 2021 but didn't find a solution
2021 ticket : https://github.com/bryntum/support/issues/3266
2021 topic : viewtopic.php?t=18405

[marcio]

Hey cds_cds_eb,

You can see in the 2021 topic a suggestion made by our dev team, besides that, I'll add a comment to the ticket.

For now, please watch that ticket for updates about the issue.

[cds_cds_eb]

Hey, thanks for the answer,
The first suggestion makes the undo unworkable fos us too, and the last suggestion (about the StateTrackingManager) its a bit confusing we didn't quite understand it, could you give us more information about what should we do?

[arcady]

The issue seems fixed as part of some other tickets. I see this code in ModelStm mixin class:

    shouldRecordFieldChange(fieldName, oldValue, newValue) {
        const store = this.firstStore;

        // By default, we do not record:
        // - not persistable field changes
        // - null vs undefined changes
        // - same value changes, compared by reference (by value for dates)
        // - "id" changes
        // - "parentId" changes caused by parent record idChange
        return !(
            this.constructor.nonPersistableFields[fieldName] ||
            (oldValue == null && newValue == null) ||
            (oldValue === newValue) ||
            ((oldValue instanceof Date) && (newValue instanceof Date) && oldValue.getTime() === newValue.getTime()) ||
            fieldName === 'id' ||
            (fieldName === 'parentId' && store && store.oldIdMap[oldValue] === store.getById(newValue))
        );
    }

So it does not record id field changes anymore. I've just checked this on the Gantt php demo and indeed id changes are not stored in undo/redo queue.

[cds_cds_eb]

I don't know if it is the id change, but for me the undo is still recording as two actions after i create a task, i'm currently on gantt 5.2.8

this is my project config:

{
			taskModelClass: Task,
			transport: {
				load: {
					url: 'php/load.php',
					paramName: 'q',
					params: {
						projetoId: idProjeto
					}
				},
				sync: {
					url: 'php/sync.php',
					params: {
						projetoId: idProjeto
					}
				}
			},
			autoLoad: true,
			autoSync: true,
			direction: this.projectModel?.direction,
			stm: {
				autoRecord: true
			},
			validateResponse: true,

		onBeforeLoad(event): boolean {
			BryntumLoadSyncUtil.addLoadParams(event.pack, 'gantt');
			return true;
		}
	};

this is my function (i just used the same as the example):

async onAddTaskClick() {
		const {gantt} = this;
		const added = gantt.taskStore.rootNode.appendChild({name: 'New task', duration: 1});

	// run propagation to calculate new task fields
	await gantt.project.propagateAsync();

	// scroll to the added task
	await gantt.scrollRowIntoView(added);

	gantt.features.cellEdit.startEditing({
		record: added,
		field: 'name'
	});
}

[arcady]

Could you try investigating your undo/redo queue to see what's there after adding a new task?

Just execute this command in console to get StateTrackingManager instance:

bryntum.query('gantt').project.stm

And then expand the object Symbol(QUEUE_PROP) property (it has an array of transactions).

1.png (140.44 KiB) Viewed 7899 times

Need to expand the array and check its transactions. I'd start checking from the last array entry (if there are multiple). Need to check the transaction Symbol(ACTION_QUEUE_PROP) property. It's an array of the transaction operations:

2.png (80.83 KiB) Viewed 7899 times

And now we need to check operations ..if you suspect registering id changes I'd check EventUpdateAction and UpdateAction entries. An entry of those types has newData property that needs to be checked to understand what changes are registered (Symbol(NEW_DATA_PROP) property):

3.png (110.88 KiB) Viewed 7899 times

Or we can check it ourselves but we're going to need a test case to reproduce the issue.

[cds_cds_eb]

Apperently it is the phantomId
i've attached de request payload and response along with the stm property

[arcady]

Ok then it must be already fixed in nightly builds. I noticed $PhantomId was there recently and fixed that. So should be ok in the next release. Thank you for the feedback!