From: Christian Egli <firstname.lastname@example.org>
Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing
Date: Thu, 25 Apr 2013 09:52:04 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
John Hendy <firstname.lastname@example.org> writes:
> On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <email@example.com> wrote:
>> You can already do so. IDs only have to be unique within the task
> 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
> 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
>> 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.
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
next prev parent reply other threads:[~2013-04-25 7:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 0:04 Item task_id not being used in taskjuggler export John Hendy
2013-04-01 0:16 ` John Hendy
2013-04-01 0:44 ` John Hendy
2013-04-01 14:21 ` Nicolas Goaziou
2013-04-01 14:53 ` John Hendy
2013-04-01 15:20 ` Nicolas Goaziou
2013-04-01 16:00 ` John Hendy
2013-04-01 16:38 ` Nicolas Goaziou
2013-04-01 16:57 ` John Hendy
2013-04-01 17:05 ` Nicolas Goaziou
2013-04-02 3:27 ` John Hendy
2013-04-01 20:56 ` Item task_id not being used in taskjuggler export & tj prefixing Buddy Butterfly
2013-04-01 20:59 ` Buddy Butterfly
2013-04-01 21:53 ` John Hendy
2013-04-01 22:01 ` Nicolas Goaziou
2013-04-02 3:24 ` John Hendy
2013-04-25 7:52 ` Christian Egli [this message]
2013-04-04 13:59 ` Buddy Butterfly
2013-04-24 20:09 ` Christian Egli
2013-04-24 19:51 ` Christian Egli
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).