emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: John Hendy <jw.hendy@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>, buddy.butterfly@web.de
Subject: Re: Item task_id not being used in taskjuggler export & tj prefixing
Date: Mon, 1 Apr 2013 22:24:28 -0500	[thread overview]
Message-ID: <CA+M2ft-vYxMOysCPOd5qesWors+LEE8+dGisSjqdyJJV=zH1CQ@mail.gmail.com> (raw)
In-Reply-To: <877gkl29m5.fsf@gmail.com>

On Mon, Apr 1, 2013 at 5:01 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>> I agree and would prefer this. Especially since folks wanting to
>> export and being allowed to access tj functionality through drawers
>> are probably going to anticipate using actual tj syntax in those
>> drawers. Since tj only forces unique global ids (one can have M.T8,
>> T.T8, etc.), this would solve the issue of ambiguity should one decide
>> to use non-globally unique task ids. In fact, many projects may very
>> well use a lot of repetitive tasks with the same properties.
>> In mine, I have some tasks regarding shipping products to various
>> countries. This way I could just have a bunch of country-specific
>> headlines like:
>> * Country
>> ** Ship product
>> * Country 2
>> ** Ship product
>> And could give all the ** Ship... tasks the same id since their
>> Country parent would make it globally unique.
> 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. Consider this  modified test file:

#+begin_src org

* Project  :taskjuggler_project:

** Milestones  :M:
*** M.M1
      :task_id: M1
      :depends: T1
*** M.T1
    :task_id:  T1
** Technical  :T:
     :task_id:  T
*** T.T1
       :task_id:  T1


The resultant TJ export:

#+begin_src tj

task milestones "Milestones" {
  purge allocate
  allocate jwhendy
  task M1 "M.M1" {
    depends !T1, !!T.T1
  task T1 "M.T1" {
task T "Technical" {
  task T1 "T.T1" {


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.

Best regards,

>> For now, I'm just happy to have functionality restored so I can use
>> Org and not hand-edit the files after exporting :) I have a potential
>> IRC date with Christian Egli sometime this week... perhaps you should
>> join and add your feedback? One of my other points of input would be
>> that something like C-c l (Org store link at point) would be great.
>> Unique ids could be inserted as depends with some simple key strokes
>> and I would't have to use numbered IDs at all. They'd stay with the
>> tasks no matter where I moved them.
>> For that... I'd actually prefer *not* to have to explicitly name the
>> parent since they could move wherever I put them with no consequence.
> 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.

Best regards,

> Regards,
> --
> Nicolas Goaziou

  reply	other threads:[~2013-04-02  3:24 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 [this message]
2013-04-25  7:52                     ` Christian Egli
2013-04-04 13:59                 ` Buddy Butterfly
2013-04-24 20:09                 ` Christian Egli
2013-04-24 19:51               ` Christian Egli

Reply instructions:

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 \
    --in-reply-to='CA+M2ft-vYxMOysCPOd5qesWors+LEE8+dGisSjqdyJJV=zH1CQ@mail.gmail.com' \
    --to=jw.hendy@gmail.com \
    --cc=buddy.butterfly@web.de \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \


* 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).