[REACT] GANTT: how to disable drag back with "memory"

[clovisapp]

Hi Bryntum team,

We need to bring a different behavior that Bryntum Gantt natively provides (you can test it in any example of Bryntum Gantt):

• if a task 1 has dependency with task 2
• if task 1 is draged in the future and "pushes" task 2 in the future
• WRONG behavior for our users: when task 1 is dragged in the past, task 2 is also pushed back in the past
• EXPECTED behavior for our users: when task 1 is dragged in the past, task 2 doesn't move.

How to disable this wrong behavior ? Thanks a lot for your help !

Here is a quick illustration to understand well

[ghulam.ghous]

Hi clovisapp,

This is the expected behaviour. In the auto scheduling mode with forward scheduling enabled, the task tends to schedule as early as possible. And in your case, as you have moved task backward, the next scheduled task (engine) gets rescheduled. To avoid this behaviour you can explore setting the task scheduling mode to manuallyScheduled.

https://bryntum.com/products/gantt/docs/api/Gantt/model/TaskModel#field-manuallyScheduled
https://bryntum.com/products/gantt/docs/guide/engine/gantt_events_scheduling#automatic-event-scheduling
https://bryntum.com/products/gantt/docs/guide/engine/gantt_events_scheduling#forward-scheduled-project

[clovisapp]

@ghulam
@Mats

I highly think automatic scheduling as default is a big mistake of the library that creates a lot of implementation hacks.

@ghulam if i set all tasks as "manuallyScheduled: true", then the dependencies don't work at all.
In my case i need to make the dependencies work, but just disabling the automatic scheduling features of Bryntum. Do you don't have any option for that ?

What is the best way to do it ?

[mats]

I highly think automatic scheduling as default is a big mistake of the library that creates a lot of implementation hacks.

It's not a mistake, it's all intentional and aligned with industry-standard project management methodologies. The above feedback from you is the first we have received in our 15 years in business.

It should be quite easy to implement the behavior you like. But first, let's dig into details. What would you expect to happen if you instead of dragging, a user updates the Task 1 start date from the TaskEditor dialog. Should it share the exact same logic as when using a drag gesture?

The solution here would be to add Lag to fill the gap between the tasks. We have a similar support for this already via the pinSuccessors mode. https://bryntum.com/products/gantt/docs/api/Gantt/feature/TaskDrag#config-pinSuccessors

[clovisapp]

@mats fully get your point. Surely other softwares prefer to develop themself their simple gantt instead of using bryntum.

It should be quite easy to implement the behavior you like. But first, let's dig into details. What would you expect to happen if you instead of dragging, a user updates the Task 1 start date from the TaskEditor dialog. Should it share the exact same logic as when using a drag gesture?

We have a custom dialog for task edition (cf screenshot). When the task is updated from this dialog we perform a modification on our backend that changes the dates of other tasks.

Our need would be to have some "Optimistic UI"

• showing the tasks moved in the frontend before the backend mutation is performed
• OR having the front end directly performing these mutations thanks to the gantt automation (or our custom logic)

[mats]

Ok thanks for the additional feedback, we'll investigate to see if we can support this as part of https://github.com/bryntum/support/issues/8898