|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001139||v3.0 Release||[All Projects] General||public||2012-05-28 03:33||2013-08-28 11:18|
|Target Version||Fixed in Version||3.0.0|
|Summary||0001139: Task dates not set correctly when importing from "template" project|
|Description||I am using 2.4 and creating projects by selecting the new project button in the projects list. |
I then give the project a start date (in this instance 21/05/2012) and select a "template" project to import tasks from.
The tasks in the template are consecutive with each task (other than the first) being dependent upon the previous one. Some tasks are milestones. The first task in the template is a milestone and has a start date of 02/06/2013 5pm
All the subsequent activities have start and finish dates that are correctly calculated from the predecessor's duration and end date.
Once the import is complete the new project shows a start date of the 21/05/2012 but the first activity's start date is still set to 02/06/2013.
|Additional Information||I thought initially that it might be to do with the dependency tracking in each of the activities but switching this on or off makes no difference to the outcome. |
I have also tried to set the "Set task start date based on dependency" flag to see if this affected things. However I'm unable to set this flag "on". Each time I set it, save the task and return to the task it set off again.
I have another template project with the same activity structure but a 1st activity start date of 25/10/12 5pm. Creating a new project with a start date of 21/05/2012 gives a first activity start date of 02/06/2013 5pm (indeed the first template was created from the second template hence the reason its first task starts on the 02/06/2013)
As suggested by Klaus I've "upgraded" to one of the trunk snapshots (2449)
However on creating a new project and importing tasks from the template I get exactly the same problem. The start date is now 29/05/2012 and the first task date calculated as 10/06/2013 (both +8 days) which seems significant.
|Tags||No tags attached.|
I'm pretty sure this one is solved here:
Please feel free to play with it.
I didn't test this, but this is what I remember and it might explain this bug:
Some (long) time ago, the decision was taken or maybe brought over from dP (which I object to - not the dP part) that in reorganising tasks they will not be shifted to the past.
Thus: templates with dates in the past were imported correctly (in an older 2 version when this was working).
If the template had a task in the future of today, that date would not have been adjusted upon import. This is excactly what is reported in this bug.
Something like tasks were forward (future) shifted, but not back shifted.
Keith, is that still in the code?
The way this works now, is that when you import a template (set of tasks) into a project, it takes the earliest date of those tasks, compares it to the project's start date, and applies that difference to every task in the template.
Therefore, if your earliest Task Start Date is 7 days before the Project Start Date, it will move all Tasks later 7 days. Alternatively, if your Project Start Date is before the earliest Task Start Date, it will move everything back.
Does that make sense?
Where things might be a little odd is when you have task dependencies like A->B->C with Dependency Tracking On.
If [A] shifts later so that it's end date is after [B]'s start date, [B] will shift back so that it's start date is the same as [A]'s end date. But if [A] shifts earlier, [B] will not also shift earlier.
The function is here:
|My eventual vision for this is that in a later version, you'll be able to specify the type of dependency - end:start, end:start with offset, end:end, and start:start - so that the system has enough knowledge on how to shift the tasks backwards or forwards as necessary.|
1) I think a template will often have dependencies on to make sense for later use.
2) In this case, for the shifting as described above, you must use a function that does not update dependencies. Reason is that after shifting, all will be consistent again, but if w2p attempts to adjust dependencies while only part of the tasks are shifted, it will/may destroy the timeline. This is similiar to the dynamic task template problem where tasks were set dynamic before their cildren were imported.
3) For all dependency tracking: I see a scenario where we want to backshift tasks, I see another where we dont want it.
a) to time optimise any given project, we want to backshift tasks. Keep track of those tasks which are only accidentally far in the future. Example: delivery time of my supplier is 2-4 months. I put receiving 4 months after order, assembly is dependent on receiving. I copy the template to a new project/order. This time, they deliver after 2 months. I complete that task (received=100%), but still assembly waits for another 2 months because it is not backshifted - WRONG
b) For capacity reasons, I want assembly to start in 6 months. Even if supplier is faster - no chance to start assembly earlier. Backshift is NOT wanted.
I think there should be back shift as standard, and a checkbox in tasks to prevent it.
I'm not sure I fully agree or disagree on your thoughts on depdendency shifting but *this* issue is how Tasks shift when you import the templates. It is a one-time event and not a part of on-going task management.
Therefore - assuming the Tasks import with the right dates - I propose we close this report and have that discussion on another (new?) ticket?
The way the tasks import is that it takes the difference (in days) between your specified Project Start Date and the earliest Task Start Date from the template. It then applies that difference (positive or negative) to all start/end dates for all the Tasks in the template.
yes, for this ticket, that sounds fine.
I may put the general discussion to the forum, it might be interesting to hear other's ideas.
|2012-05-28 03:33||paul_rogers6||New Issue|
|2012-07-08 20:39||caseydk||Project||v2.4 Release (Closed) => v3.0 Release|
|2012-11-24 22:56||caseydk||Note Added: 0002711|
|2012-11-24 22:56||caseydk||Status||new => feedback|
|2012-11-25 07:32||opto||Note Added: 0002714|
|2012-11-25 23:49||caseydk||Note Added: 0002723|
|2012-11-25 23:49||caseydk||Note Added: 0002724|
|2012-11-26 03:37||opto||Note Added: 0002726|
|2012-11-26 12:01||caseydk||Note Added: 0002732|
|2012-11-26 13:05||opto||Note Added: 0002734|
|2012-11-26 13:53||caseydk||Note Added: 0002735|
|2012-11-26 13:53||caseydk||Status||feedback => resolved|
|2012-11-26 13:53||caseydk||Resolution||open => fixed|
|2012-11-26 13:53||caseydk||Assigned To||=> caseydk|
|2013-08-28 11:14||caseydk||Fixed in Version||=> 3.0.0|
|2013-08-28 11:18||caseydk||Status||resolved => closed|