MantisBT - Pending Requests
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001600Pending RequestsTaskspublic2014-08-07 10:212016-12-26 10:25
Reporteropto 
Assigned Toopto 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001600: Importtasks broken for dynamic tasks
Description1) bug, 2) feature request

project has one chain of children:

ddd (D) 15.6.-21.6.
-aaaa 15.6.-15.6.
--bbb (D) 19.6.-21.6.
---ccc 21.6.-21.6.
----dur 19.6.-19.6.

all have 1 -4 hours duration

ddd and bbb are dynamic (D)
project start May 1st, first task starts Jun 15th.

1) bug:
import into new project starting May 1st looks not good.
import into new project starting Jun 15th (=start of aaaa and therefore also ddd):
new ddd has no start and end
bbb does not take over dur's start nor dur's duration

updatedynamics called in the wrong place?

If, in original project, the first task does not start on first project day, it seems that cannot be reproduced (imported).

In a template, that might make sense if tasks should be inserted there after import.

2) I would also calculate the shifting differently, so that the time distance of task start to project start in new and old project is the same.
Otherwise, on import, we change the project structure.
And if someone has designed it that project start unequal start of first task, software shouldn't be entitled to change that.

Or: have a true copy of projects. Then I could shift the start date of everything in projectdesigner. I think we need one or the other.

Klaus
TagsNo tags attached.
Relationships
Attached Files

Notes
(0003587)
opto   
2014-08-09 04:40   
(Last edited: 2014-08-09 04:42)
yes, sometimes it works.

I tried another combination of dates and then it is ok.

It seems it depends on the order in which the dynamics are updated.

Also I noticed (maybe by design): if a child is saved, only its own date is updated in the dynamic parent.

I had a sutuation where the dynamic task had not taken over any date.

Also, the datetime fields of the dynamic should probably be disabled by javascript if set to dynamic
saving dynamic task: no update dynamics.
saving child that ended earlier: its date was entered into the dynamic task, but not the correct task ending later.

saving that task obviously mmade end dates correct.

Didn't try yet what happens with start date.

The problem might be solved if saving the dynamic task would update its dynamics.
(0003651)
caseydk   
2014-09-20 19:11   

The big problem with a dynamic updating the dynamics is that we could get caught in a loop.. we need to keep track of all the times a task *should* update and once it shouldn't be updated anymore, update it once. But then that sets off another chain reaction that.. yeah.

Is this a showstopper as is? As in "can we push figuring this out to v4?"

Issue History
Date ModifiedUsernameFieldChange
2014-08-07 10:21optoNew Issue
2014-08-09 04:40optoNote Added: 0003587
2014-08-09 04:42optoNote Edited: 0003587bug_revision_view_page.php?bugnote_id=3587#r95
2014-09-20 19:11caseydkNote Added: 0003651
2014-09-20 19:11caseydkAssigned To => opto
2014-09-20 19:11caseydkStatusnew => feedback
2014-09-21 12:44caseydkProjectv3.2 Release => v4.0 Release (Planning)
2014-10-12 12:50caseydkTarget Version => 4.0
2016-12-26 10:25caseydkProjectv4.0 Release (Planning) => Pending Requests