|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001474||v3.2 Release||Tasks||public||2014-04-05 09:38||2014-07-16 21:27|
|Target Version||3.2||Fixed in Version||3.2|
|Summary||0001474: child can no longer depend on parent - breaks old projects|
|Description||1) I do not really a reason why a child could not depend on its parent (unless the parent is dynamic).|
I can even see some scenarios where this is useful - a smaller amount of umbrellatasks is needed.
2) In any case, this seriously breaks old projects. Up to now, this was allowed.
Now, if such a task is opened for eiting, the saving is not allowed.
As a consequnce, nobody knows what to do - yes, I can see that this task was made dependent on its parent a year ago - but today, how to resolve this without a specialist? Project workers without this knowledge are no longer able to work on tasks.
please don't make this a compulsury rule for task layout. It may be convenient in some scenarios - but not in others. For us, it a p. in the a.. all our database is unusable with this new restriction, tons of projects would need to be revisited and changed with nobody knowing how to resolve this for the projects (except me, and I really want to be bothered with this extra work).
Also, I see this as nice, but not really must or breaking if not implemented. And in some scenarios, the old practice even makes sense ...
|Tags||No tags attached.|
This *looks* like it was only allowed before because the Project Designer used raw database updates instead of the $task->store() method. Once I updated it to use the proper store() - necessary to make sure dependencies, dynamics, etc all update - it added the constraint.
|2014-04-05 09:38||opto||New Issue|
|2014-04-05 09:57||caseydk||Note Added: 0003292|
|2014-04-05 09:57||caseydk||Status||new => resolved|
|2014-04-05 09:57||caseydk||Resolution||open => fixed|
|2014-04-05 09:57||caseydk||Assigned To||=> caseydk|
|2014-04-13 18:51||caseydk||Target Version||=> 3.2|
|2014-07-16 21:26||caseydk||Fixed in Version||=> 3.2|
|2014-07-16 21:27||caseydk||Status||resolved => closed|