Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Task not rescheduled when altering #1247
I found the following issue exists in ver. 2.7.2: when a task_1 has a dependency on a preceding task_0, if task_0 is deleted then task_1 should be rescheduled to start asap (still respecting any other dependencies).
However what actually happens when task_0 is deleted is that the dates for task_1 stay the same. See before/after screenshots below.
The same issue occurs if the dependency is removed (erasing the predecessor column): task_1 should be rescheduled earlier, but actually it does not update.
I am not aware of any workarounds.
It is absolutely not obvious why task_1 should be rescheduled in this case and what date should be its start date, provided that there are no other dependencies. Today's date? Project start date? Current viewport start date? Jan 1st year 0000?
One may argue that it should be the date entered when task was created, this sounds more reasonable, although in practice, when tasks are just created one-by-one hitting Ctrl+T it will also be unexpected for the user.
This said, if you know a date where task_1 should jump to, the workaround is to create a task/milestone at that date and create a strong dependency between that milestone and task_1. When you delete task_0, the dependency will force task_1 to move backwards.
See also #1124
In my opinion, it should be rescheduled to the project start date, as it is the earliest possible date.
To elaborate, scheduling options for a task are:
When the "additional constraint" field is empty, a task should start asap (dependencies permitting). In fact, GanttProject schedules any newly created task to start on the project start date, which I think is the correct behaviour.
For consistency, I think the same should occur to a task when removing all its dependencies. If also no constraint exists, then the task should be rescheduled to the project start date (even if it is in the past). This is consistent with MS Project
Further, the behaviour I suggest helps the user identify a common source of mistake: given a sequence of interdependent tasks 1 -> 2 -> 3, if task 2 is removed the user should manually add a dependency from 1 -> 3. Automaticaly rescheduling task 3 to the project start date allows the user to immediately realise that it has become "unbound" and correct it by creating the dependency.
Conversely, leaving task 3 to its current date hides this problem. As a result, if task 1 is subsequently increased in duration and its start date moves to after the start of task 3, a logical inconsistency occurs. This occurs very frequently in practice, when working with complex sequence of activities, as it is difficult to find all the tasks which are dependent on a given task to be removed.
This is just my opinion - for reference I work in project management and am a MS Project user :)
Not sure that MS Project behavior worth copying in this case. Many people like GanttProject because it doesn't try to be too clever and get confused when tasks move even in those scenarios when they really have to move because of dependencies or because it is a summary task (see e.g. this discussion http://forum.ganttproject.biz/view/20140407200548_2peee67uiz62516p4l9xcwewc or many other similar by keywords "change dates"). People normally love when they control things.
Indication that some tasks need may attention might be good. Suggestion to create dependency 1 -> 3 in the scenario given above would be awesome. Automated arguable actions in my opinion should be avoided.
No, the start date of a newly created task is the start date of the currently visible chart area. There is a good reason behind: when you create a new task, you expect it to appear on the chart. If we set the start date to the project start date, it is possible that newly created task will appear somewhere outside the visible chart area, and it is also what confuses users.
I see your point, agree different users may have different expectations. Personally I prefer to know the software has a simple, consistent behaviour (i.e. every task starts asap at all times).
I have the same problem. I need to have tasks begin as soon as possible. And, after reproducing this current issue, I have this weird result : https://postimg.org/image/5vqg5b417/
Actually, I handle it manually; I change end date for needed task to a date before the project. And, Gantt project semi-automatically fix this. That's annoying.