[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Item task_id not being used in taskjuggler export & tj prefixing
From: |
Christian Egli |
Subject: |
Re: [O] Item task_id not being used in taskjuggler export & tj prefixing |
Date: |
Thu, 25 Apr 2013 09:52:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
John Hendy <address@hidden> writes:
> On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <address@hidden> wrote:
>> You can already do so. IDs only have to be unique within the task
>> siblings.
>
> True, one can name tasks identically as long as they have no identical
> siblings... but the point was the since one can only specify the
> lowest level of id (e.g. "T1" instead of "T.T1"), Org doesn't know how
> to resolve them properly.
AFAIK task_ids have to be globally unique if you want to use them for
dependencies.
> Task M1 ends up depending on both M.T1 (represented as !T1) /and/
> T.T1. It won't fail since both T.T1 and M.T1 exist, but the user has
> no way to set a depends option to target the specific T1 they wanted.
> Setting =:depends: !!T.T1= ignores the :depends: property entirely.
The TaskJuggler exporter gives you 3 ways to express a dependency:
1. using ORDERED on the parent task
2. using "previous-sibling"
3. using a task_id of another task. This has to be a unique id,
otherwise you end up depending all the other tasks that have this
task_id.
>> You don't have to name parents either. You only need to name tasks that
>> will be used as a dependency.
>
> True, which is nice. But we're torn between:
> - Letting Org name the parent whatever it wants, but then having to
> figure out the org-generated parent id so we can do =:depends:
> parent.subtask=, or
>
> - Specifically naming the parent to have control over the task_id, but
> having to change it because we move it later (and then updating all
> =:depends: parent.task_id= properties accordingly)
>
> And in either case, there's still no way to depend on a specific
> =parent.task_id= combination.
I don't understand this. Why do you need to name parents (or assign them
a task_id)? As Nicolas says: all you have to do is to give the task you
want to depend on a task_id.
As an aside I thought you could also use plain ID to express
dependencies. But from looking at the code this doesn't seem supported.
I think the reason why yet another id (namely task_id) is used, is that
this allows for short human readable ids where as the standard ID is
generally generated by org mode and is cryptic and much longer.
HTH
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
- Re: [O] Item task_id not being used in taskjuggler export, (continued)
- Re: [O] Item task_id not being used in taskjuggler export, John Hendy, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export, Nicolas Goaziou, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export, John Hendy, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export, Nicolas Goaziou, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export, John Hendy, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, Buddy Butterfly, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, Buddy Butterfly, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, John Hendy, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, Nicolas Goaziou, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, John Hendy, 2013/04/01
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing,
Christian Egli <=
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, Buddy Butterfly, 2013/04/04
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, Christian Egli, 2013/04/24
- Re: [O] Item task_id not being used in taskjuggler export & tj prefixing, Christian Egli, 2013/04/24