Notice how moving a task results in the root node changing its start date, while the remaining tasks retains their start date. But once I reload gantt (this could be done by a different user on a different computer), he/she will see a different result as the automatic scheduling kicks in and changes the start date of the remaining tasks.
How do we fix this? It's a problem that users expect gantt to look like X when saved, but when data is loaded by another user, it looks like Y - completely different.
The case X - when the parent task date changes, the automated scheduled tasks are not moving and retaining the position. This is happening because there is no constraint of parent task on these child tasks. There's only one constraint and that is of the project start date. So as they are starting after the project start date, they are not re-scheduled. About second case, as you can see the project is reloaded, the tasks start date is probably recalculated and as the project has a updated start date, the child tend to be scheduled accordingly. So I am afraid this is by design.
Unfortunately this poses a problem for us. We can't have a situation where a user saves data, and it ends up completely different after being reloaded - potentially by a different user. What-you-see-is-NOT-what-you-get.
@Mats, would you mind bringing this problem to the developer team's attention. Is there really nothing that can be done to solve this problem? If Gantt is capable of calculating a new start date for the project on reload, then why can't it do it on-the-fly ?
It happens since your dataset does not provide the project startDate value.
In this case the Gantt will try calculating it based on provided dataset.
And this is what it does after you click the button.
after doing this I had to change tasks constant definition in App.ts:
// @ts-ignore
const tasks = ganttConfig.project.tasksData as TaskModelConfig[];
Not sure what that code does.. I just silenced TS error there since my intention was just to provide startDate to the project and see what happens. And after I did that it started to work. The project has its start defined and no longer tries to calculate it based on its data.
I'd like to add to Jimmy's description of the problem that we do not necessarily have an outer startDate constraint.
The fact that the scheduler deduces a startDate from the whole plan, is a neat feature we rely on. We need that to happen on the fly when the plan changes, not only when it loads (i.e. an event is dragged to a new earliest point in plan). It is as simple as that really.
As you expand the plan to one side or the other, automatically scheduled events are expected to follow immediately, not after reload.
The project startDate is a required value based on which all tasks are scheduled. The tasks are scheduled ASAP given the earliest possible date is the project start. So moving the date causes moving of the project tasks (this is what you reported in this post).
It's meant to be provided ..if not it's calculated but that happens only once and after that the value has to be persisted. This by design.
You can skip the value and then it's calculated. But the value is part of the data and has to be persisted to the server side after it's calculated. So when reloading the data the value should be there and then tasks won't jump.
