Anonymous Login
2020-08-14 09:54 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000647v2.2 Release (Closed)[All Projects] Generalpublic2010-12-19 13:18
Assigned Totrevormorse 
Product Version 
Target VersionFixed in Version2.2 
Summary0000647: When importing tasks into new project tasks start/end dates are not recalculated based on new project's start date
DescriptionWhen creating a new project the option exists to import tasks from an existing project. The start and end dates for any such tasks should be adjusted based upon the new projects start date and each tasks duration/predecessor's end date. This is not happening. Instead all the imported tasks maintain their original start and end dates.
TagsNo tags attached.
Attached Files

related to 0000645closedcaseydk v2.3 Release (Closed) When tasks are imported from another project no reminders are added to the event queue 
related to 0000620closedcaseydk Third-party Modules Importing tasks from another project leads to parent issues 
has duplicate 0000391closedtrevormorse v2.3 Release (Closed) Importing all tasks from another project (template) does not importing dependancies of source tasks 



caseydk (administrator)

Actually, it's working exactly as designed.. it just wasn't designed the right way.

Basically, you envision the flow to use the existing Project Start Date as a "starting offset" and have it calculate forward from there. Correct?


paul_rogers6 (reporter)

Hi Keith

I set up a test harness. As far as I can see the import function takes the original project's and the new project's start dates and uses these to calculate the correct offset. It then correctly calculates each task's starts and end date. If I output each task object (for the new project)immediately before the call to the store function it has the correct start and end dates.

However the values are stored seem to be almost random. I've tried importing from different projects with different tasks. All our projects start with a milestone starting on a specific date at 08:00 and are then followed by a task that starts at on the same date and at the same time as the milestone. This is the only thing the projects have in common. Each task is dependent on the previous task.

Now when I import the second task sometimes is updated to start on the project start date but on some of the tests the project start date is set to the 29/11/2010 and the second task start date is created as the 27/11/10!! Any subsequent tasks/milestones are updated relative to the second task not the project start date.

Attached are the test harness code, the modified importTasksTest function (in projects.class.php and the output from the test harness.

From what I can see the function works as anticipated until the store function. The logic of the function seems correct also.


trevormorse (manager)

Hi there,

I have done some testing with the files you have sent along and am seeing some weirdness as well.

Could I get you to try something, to see if we can get a little more information.

In the projects.class.php you sent along around line 305 change:



$response = $newTask->store($AppUI);

Then on a new line following this one please add:

echo 'Response: ' . $response . '

Once you have made that modification, please re-run and let me know what shows up in the response.




paul_rogers6 (reporter)

Last edited: 2010-12-06 06:10

Hi Trevor

Attached is the output from the amended importTasksTest function.

The $response variable seems to contain nothing. Also even when the store function is called nothing is added to the database (had tried this previously with out returning response, with same result). I do note however that I have created a new instance of CAppUI, for passing onto the store function, but have no idea whether it has the correct session variables etc set to work as required by the store function.

Also attached are 4 html files (template1, template2, import1 and import2). Each of the template files shows the tasks for the two projects I've been testing on (using the w2P interface to create and import tasks), while each of the import files show the corresponding & resulting projects with their imported tasks.

I'm sure when I started testing some weeks ago that all the tasks (in the new project) were left with the same start and end dates as the templates but now every time I test only the initial task is broken. Weird!! Even weirder is the fact that I'm sure when we started importing projects some months ago everything worked fine.

Finally one other thing I notice that may or may not be related. If I create a new project with no tasks the projects list shows the project as having 0 tasks. If I then import some tasks and delete all of them again the projects list shows the project as having 1 task. A select on the tasks table with the relevant task_project returns an empty set.

Hope that in someway helps.




trevormorse (manager)

Hi Paul,

Thanks for sending this along. From what I see in your template and import files it appears as though the first task(milestone) is not being updated based on the new projects start date, while the rest are. Does that sound right? That is what I encountered while testing on my system as well :)

Not having the proper AppUI may definitely be causing some issues. Could you add the following code after the line that you create the new $AppUI object in your testharness.php file, substituting your login information for that of the admin user, and try running it again.

$_POST['login'] = 'login';
$_REQUEST['login'] = 'sql';
$AppUI->login('admin', 'passwd');




paul_rogers6 (reporter)

Hi Trevor

As you say it appears that whenever I import tasks from a project the only item not being updated is the first task. All others seem to be updated correctly

I've updated the testharness as suggested and the response is now being generated, the copy function's output is no longer displayed and when I check the project in the w2P interface the two tasks have been imported (see attached testharness.php.out.html). So the importTasksTest function now seems to be working the same as the original importTasks function.

As you can see from the attached import1.html the import works the same, ie first task is not updated while the remaining task is updated.

I've also run the testharness on the template with 13 tasks and the output/result is the same (see attached testharness2.php.out.html), ie first task remains same while others are updated.

Hope that helps & thanks for all your efforts.




trevormorse (manager)

Hi Paul,

Thanks for sending this along.

This confirms what I had thought it might be. Essentially what is happening is that once all the tasks have been created with the original dates and dependencies created, the system goes through and updates them based on the new project dates.

One of the checks the system has in place is failing for the first task/milestone and causing it not to get updated with the new dates. Causing the bug you are seeing.

I'll keep you posted on how I make out fixing it.



trevormorse (manager)

Hi Paul,

I believe I have this fixed. It should be pulled in to subversion/sourceforge sooner rather then later hopefully.

In the meantime, if your feeling ambitious and have a test w2p install it would be great if you could confirm this! :-)

You can see my commit here -

The only relevant line is 227 in the tasks.class.php file. If you could replace that line with whats in the commit and let me know if it fixes the bug for you it would be greatly appreciated :-)




trevormorse (manager)

Fixed here -


caseydk (administrator)

In v2.2 release.

-Issue History
Date Modified Username Field Change
2010-11-25 23:28 paul_rogers6 New Issue
2010-12-03 12:09 caseydk Note Added: 0001391
2010-12-03 12:37 caseydk Project v2.1 Release (Closed) => v2.2 Release (Closed)
2010-12-03 23:11 caseydk Relationship added related to 0000645
2010-12-03 23:12 caseydk Relationship added related to 0000620
2010-12-04 10:59 paul_rogers6 Note Added: 0001401
2010-12-04 11:10 paul_rogers6 File Added:
2010-12-05 11:08 trevormorse Status new => assigned
2010-12-05 11:08 trevormorse Assigned To => trevormorse
2010-12-05 11:22 trevormorse Note Added: 0001402
2010-12-06 06:08 paul_rogers6 Note Added: 0001404
2010-12-06 06:08 paul_rogers6 File Added:
2010-12-06 06:09 paul_rogers6 Note Edited: 0001404
2010-12-06 06:10 paul_rogers6 Note Edited: 0001404
2010-12-06 09:10 trevormorse Note Added: 0001405
2010-12-07 00:20 paul_rogers6 Note Added: 0001408
2010-12-07 00:20 paul_rogers6 File Added:
2010-12-07 05:43 trevormorse Note Added: 0001409
2010-12-07 17:07 trevormorse Note Added: 0001413
2010-12-07 17:08 trevormorse Note Added: 0001414
2010-12-07 17:08 trevormorse Status assigned => resolved
2010-12-07 17:08 trevormorse Fixed in Version => 2.2
2010-12-07 17:08 trevormorse Resolution open => fixed
2010-12-12 15:55 trevormorse Relationship added has duplicate 0000391
2010-12-19 13:18 caseydk Note Added: 0001451
2010-12-19 13:18 caseydk Status resolved => closed
+Issue History