Task not rescheduled when altering #1247

Closed
Lodf opened this Issue Apr 27, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@Lodf

Lodf commented Apr 27, 2016

Hello,

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.

screenshot

@dbarashev

This comment has been minimized.

Show comment
Hide comment
@dbarashev

dbarashev Apr 27, 2016

Contributor

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

Contributor

dbarashev commented Apr 27, 2016

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

@Lodf

This comment has been minimized.

Show comment
Hide comment
@Lodf

Lodf Apr 27, 2016

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:

  • start asap (this is the default we use in project management and is limited backwards to the project start date)
  • start as late as possible without delaying tasks on the critical path
  • start no earlier than x
  • finish no later than x

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 :)

Lodf commented Apr 27, 2016

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:

  • start asap (this is the default we use in project management and is limited backwards to the project start date)
  • start as late as possible without delaying tasks on the critical path
  • start no earlier than x
  • finish no later than x

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 :)

@dbarashev

This comment has been minimized.

Show comment
Hide comment
@dbarashev

dbarashev Apr 27, 2016

Contributor

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.

GanttProject schedules any newly created task to start on the project start date,

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.

Contributor

dbarashev commented Apr 27, 2016

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.

GanttProject schedules any newly created task to start on the project start date,

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.

@Lodf

This comment has been minimized.

Show comment
Hide comment
@Lodf

Lodf Apr 27, 2016

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).
Perhaps a future version there could have an option for the user to choose the preferred behaviour in such scenarios, e.g. do not reschedule, reschedule to visible window, reschedule to earliest date, inherit deleted task dependencies.
For the moment I'll use your workaround, I'll just need to remember to manually update the successors' predecessors before removing a task :)

Lodf commented Apr 27, 2016

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).
Perhaps a future version there could have an option for the user to choose the preferred behaviour in such scenarios, e.g. do not reschedule, reschedule to visible window, reschedule to earliest date, inherit deleted task dependencies.
For the moment I'll use your workaround, I'll just need to remember to manually update the successors' predecessors before removing a task :)

@mikefaille

This comment has been minimized.

Show comment
Hide comment
@mikefaille

mikefaille Jun 8, 2016

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/
I think have task beginning as soon as possible could greatly help to reduce management time. And, I'm sure lots of project manager want this feature. Maybe implement this as an option.

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.

mikefaille commented Jun 8, 2016

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/
I think have task beginning as soon as possible could greatly help to reduce management time. And, I'm sure lots of project manager want this feature. Maybe implement this as an option.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment