Anonymous Login
2019-12-10 14:54 PST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001600Pending RequestsTaskspublic2016-12-26 10:25
Reporteropto 
Assigned Toopto 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusfeedbackResolutionopen 
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.
Attached Files

-Relationships
+Relationships

-Notes

~0003587

opto (manager)

Last edited: 2014-08-09 04:42

View 2 revisions

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 (administrator)


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?"
+Notes

-Issue History
Date Modified Username Field Change
2014-08-07 10:21 opto New Issue
2014-08-09 04:40 opto Note Added: 0003587
2014-08-09 04:42 opto Note Edited: 0003587 View Revisions
2014-09-20 19:11 caseydk Note Added: 0003651
2014-09-20 19:11 caseydk Assigned To => opto
2014-09-20 19:11 caseydk Status new => feedback
2014-09-21 12:44 caseydk Project v3.2 Release => v4.0 Release (Planning)
2014-10-12 12:50 caseydk Target Version => 4.0
2016-12-26 10:25 caseydk Project v4.0 Release (Planning) => Pending Requests
+Issue History