Anonymous Login
2022-09-26 11:17 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001255v3.0 Release[All Projects] Generalpublic2015-09-05 10:55
Assigned Tocaseydk 
Product Version 
Target VersionFixed in Version3.0.0 
Summary0001255: Importing milestones may cause "CTask::store-check failed - task start date is after task end date"
DescriptionLet's say we have a project template with a bunch of tasks and want to import those tasks into a new project with a new start date.
When after shifting all the dates a task with duration 0 (e.g. milestone) falls on a not_working_day, the task class will move the start_date to next_working_day (task.class.php Line: 554). So now we already have start_date > end_date.

A couple lines later (560 - 562) it tries to move the end_date to a working_day, but it moves it to prev_working_date making the difference even bigger.
When the time comes to validate the new task (task.class.php Line 126 - 160 isValid()), it fails and spits out the error message:
"CTask::store-check failed - task start date is after task end date".

Moving end_date to next_working_day instead of prev_working_day seems to solve it, but I've only tested this with milestones (duration 0). I can imagine this happening with other short duration tasks and long weekends.
TagsNo tags attached.
Attached Files




caseydk (administrator)



lukeD (reporter)

Last edited: 2013-06-03 08:04

Although the fix helped, I'm still occasionally getting the "CTask::store-check failed - task start date is after task end date" error when importing milestones.

I was able to trace it back to the addDuration method in Date.class.php.
Line 264:
($sgn > 0) ? $this->next_working_day() : $this->prev_working_day();

Your patch uses the following to calculate the end date:
$new_start_date->addDuration($orig_task['task_duration'], $orig_task['task_duration_type']);

Since this is a Milestone, it's duration is 0, therefore $sgn = w2Psgn($duration) = 0.
So adding duration=0 to a date causes it to move to the previous day.

I tried ($sgn >= 0) in line 264 and it works. I don't know what side effects this could have though.


caseydk (administrator)


-Issue History
Date Modified Username Field Change
2013-02-28 02:37 lukeD New Issue
2013-03-02 22:49 caseydk Note Added: 0002814
2013-03-02 22:49 caseydk Status new => resolved
2013-03-02 22:49 caseydk Resolution open => fixed
2013-03-02 22:49 caseydk Assigned To => caseydk
2013-06-03 08:00 lukeD Note Added: 0002937
2013-06-03 08:00 lukeD Status resolved => feedback
2013-06-03 08:00 lukeD Resolution fixed => reopened
2013-06-03 08:04 lukeD Note Edited: 0002937
2013-06-08 21:21 caseydk Note Added: 0002941
2013-06-08 21:21 caseydk Status feedback => resolved
2013-06-08 21:21 caseydk Resolution reopened => fixed
2013-08-28 11:14 caseydk Fixed in Version => 3.0.0
2013-08-28 11:17 caseydk Status resolved => closed
+Issue History