Premium support for our pure JavaScript UI components


Post by msaliba »

Hello,

A question for you regarding changes on a Gantt and event propagation.

Let's say a user moves a task on the Gantt which then shifts several downstream tasks due to the dependencies between them. As an example, if we look at the basic example and move the "Hire QA staff" from January 14 to January 15, all tasks below also get updated.

An event handler will catch all the changes as an array of updates:

project: {
    ...,
    listeners: {
        hasChanges() {
            console.log(this.changes);
        }
    },
},

Is there any way to distinguish which of the updates was the original change versus the subsequent propagated changes?

From an auditing standpoint, this would help us differentiate and record changes that a user intentionally made from other changes that were propagated by the "system".


Post by marcio »

Hey msaliba,

Thanks for reaching out.

You can get the first change of that array, you'll see the id of the task which is the first one that was modified.

Attachments
Screenshot 2025-01-13 at 17.44.15.png
Screenshot 2025-01-13 at 17.44.15.png (269.41 KiB) Viewed 293 times

Best regards,
Márcio

How to ask for help? Please read our Support Policy


Post by msaliba »

Hey Marcio,

I thought that might be the case but this example doesn't appear to work the same way.

The data is the same, and moving the same task ("Hire QA staff" with id = 31), the update appears as the update with index = 23.

Any idea why it's different here?

Screenshot 2025-01-13 at 13.02.08.png
Screenshot 2025-01-13 at 13.02.08.png (1.77 MiB) Viewed 290 times

Post by marcio »

Hey,

Hey, unfortunately, the hasChanges doesn't suit the behavior you need.

But we have our versioning feature - https://bryntum.com/products/gantt/docs/api/Gantt/feature/Versions - which you can see live on our demo - https://bryntum.com/products/gantt/examples/versions/ - which fits exactly what you described (check the changeLogModel, which contains the action that the user performed separated from the "system changes").

If you need further clarification, please don't hesitate to contact us here.

Best regards,
Márcio

How to ask for help? Please read our Support Policy


Post by msaliba »

Ah, interesting that this works at the Gantt level rather than the Project level.

Thank you for your help, I was finally able to get a simple POC working correctly (see attachment).

As a follow-up question, how do the versions work in conjunction with the CRUD manager's sync function? Does enabling STM and versions affect the format of the request data that is sent via the sync API call?

Attachments
Screenshot 2025-01-14 at 17.56.17.png
Screenshot 2025-01-14 at 17.56.17.png (1.87 MiB) Viewed 264 times

Post by ghulam.ghous »

As a follow-up question, how do the versions work in conjunction with the CRUD manager's sync function? Does enabling STM and versions affect the format of the request data that is sent via the sync API call?

Nope. It does not effect the sync request structure. The structure will be the same as with STM disabled.


Post by msaliba »

Thanks Ghulam.

Is it correct then that the first ChangeLogUpdateAction is always the user-triggered action and the following ones are the propagated changes? The documentation seems to indicated that the "isUser" flag should be true in that case but it was not in the last example I shared. Did I miss anything?

Second, and this brings us back to the original question: using versions I can differentiate user changes versus propagated system changes, but it doesn't change how the data is sent via the sync function. How would you recommend reconciling the two so that our backend can distinguish user versus system changes?


Post by marcio »

Hey msaliba,

That's not mandatory for the first action to be the user-triggered action.

Besides that, You didn't miss anything, that looks like a bug on our side, as it should have at least one action with the isUser flag being set to true. Please follow the updates here https://github.com/bryntum/support/issues/10615.

With the flag working correctly, perhaps you could store that info on one variable, which will be checked when the sync function is being executed, but we will need to fix that flag first.

Best regards,
Márcio

How to ask for help? Please read our Support Policy


Post by msaliba »

Ah, so it's a bug! Okay great, I will keep an eye on the ticket.

Would it be possible to add the "isUser" flag to the request data in the sync function? That seems to be the simplest way to solve this scenario. Is that an easy change to make? I only ask because maybe it's easier for you guys to expose the information internally instead of me having to enable versions and STM, and then hack the two together.

Alternatively, if the sync function could send the ChangeLog events directly to the backend, that would also be a clean implementation.

Curious to hear your thoughts and really appreciate the ongoing conversation!


Post by alex.l »

Hi,

Thanks for the question!

Would it be possible to add the "isUser" flag to the request data in the sync function? That seems to be the simplest way to solve this scenario. Is that an easy change to make? I only ask because maybe it's easier for you guys to expose the information internally instead of me having to enable versions and STM, and then hack the two together.

There is another question: if users really need that information in the request data. This sounds like not common business logic use case. Anyway we will analyse it deeply when we will fix the issue.

All the best,
Alex Lazarev

How to ask for help? Please read our Support Policy

We do not write the code in bounds of forum support. If you need help with development, contact us via bryntum.com/services


Post Reply