Re: Setting taskjuggler project start date (ox-taskjuggler)

[Christian Egli <christian.egli@sbs.ch>]

John Hendy <jw.hendy@gmail.com> writes:

> On Wed, Mar 27, 2013 at 9:37 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> Hello,
>>
>> John Hendy <jw.hendy@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