John Hendy <jw.he...@gmail.com> writes: > On Wed, Mar 27, 2013 at 9:37 AM, Nicolas Goaziou <n.goaz...@gmail.com> wrote: >> Hello, >> >> John Hendy <jw.he...@gmail.com> writes: >> >>> If you have =org-taskjuggler-keep-project-as-task=, it will take the >>> :start: property and use this in the project-as-top-level-task output. >>> Could this be used after =scheduled= and before defaulting to today's >>> date? This would seem to unify the syntax. >>> >>> It strikes me as reasonable to take 1) scheduled, 2) :start: in >>> property drawer and 3) default to today's date (in that order).
I just pushed a change that should implement this the way you describe above. > Also, since I noticed that my tasks pick up the :start: property and > that the get-start (item) function *could* pick up a scheduled date as > well... might be good to anticipate the case in which the user > specifies both (probably accidentally). Maybe just provide an error > that either scheduled/deadline *or* :start: should be used, but not > both. Currently the org-taskjuggler-get-start function is only used to determine the start of a project or when checking if a task is a milestone (ie has neither a start nor an end), so the problem above is independent of that. But yes it is a problem: if you schedule a task and add a start attribute you will most likely have two start attributes for that task in your tjp file and the tj3 compilation will fail. Wouldn't this be sufficient? > Or if scheduled date conflicts with an duration/dependency > relationship as well? What do you mean? This to me sounds like it's the job of tj3. > Some of this might be handled by the tj3 command on the resultant .tjp > file, though. Yes, my sentiments exactly :-) Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
