Request new features or modifications


Post by 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


Post by 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.

Best regards,
Márcio


Post by 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?


Post by 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.


Post by 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'
	});
}

Post by 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
1.png (140.44 KiB) Viewed 5076 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
2.png (80.83 KiB) Viewed 5076 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
3.png (110.88 KiB) Viewed 5076 times

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


Post by cds_cds_eb »

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

Attachments
Clipboard - 30 de Março de 2023 às 10_22 (3).png
Clipboard - 30 de Março de 2023 às 10_22 (3).png (76.58 KiB) Viewed 5064 times
Clipboard - 30 de Março de 2023 às 10_22 (2).png
Clipboard - 30 de Março de 2023 às 10_22 (2).png (40.42 KiB) Viewed 5064 times
Clipboard - 30 de Março de 2023 às 10_22 (1).png
Clipboard - 30 de Março de 2023 às 10_22 (1).png (82.99 KiB) Viewed 5064 times

Post by 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!


Post Reply