MantisBT - v3.0 Release
View Issue Details
0001255v3.0 Release[All Projects] Generalpublic2013-02-28 02:372015-09-05 10:55
Assigned Tocaseydk 
PlatformOSOS Version
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

2013-03-02 22:49   
2013-06-03 08:00   
(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.

2013-06-08 21:21   

Issue History
2013-02-28 02:37lukeDNew Issue
2013-03-02 22:49caseydkNote Added: 0002814
2013-03-02 22:49caseydkStatusnew => resolved
2013-03-02 22:49caseydkResolutionopen => fixed
2013-03-02 22:49caseydkAssigned To => caseydk
2013-06-03 08:00lukeDNote Added: 0002937
2013-06-03 08:00lukeDStatusresolved => feedback
2013-06-03 08:00lukeDResolutionfixed => reopened
2013-06-03 08:04lukeDNote Edited: 0002937
2013-06-08 21:21caseydkNote Added: 0002941
2013-06-08 21:21caseydkStatusfeedback => resolved
2013-06-08 21:21caseydkResolutionreopened => fixed
2013-08-28 11:14caseydkFixed in Version => 3.0.0
2013-08-28 11:17caseydkStatusresolved => closed