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:
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".
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 (1.87 MiB) Viewed 264 times
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.
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?
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.
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!
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.