From: John Hendy <jw.hendy@gmail.com>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Item task_id not being used in taskjuggler export
Date: Sun, 31 Mar 2013 19:44:18 -0500 [thread overview]
Message-ID: <CA+M2ft80S5XXv9JtRjQxNXoJ5FawHkmjSTU806Je-CyR-VcDdA@mail.gmail.com> (raw)
In-Reply-To: <CA+M2ft-OuardNZ-UJZQAVCvgGZKkcSdihL1=6ijPsQF3P=1AaA@mail.gmail.com>
On Sun, Mar 31, 2013 at 7:16 PM, John Hendy <jw.hendy@gmail.com> wrote:
> On Sun, Mar 31, 2013 at 7:04 PM, John Hendy <jw.hendy@gmail.com> wrote:
>> I seem to be having trouble getting custom task_id values used for my
>> taskjuggler file. From ox-taskjuggler.el:
>>
>> #+begin_quote
>> (defun org-taskjuggler--build-task (task info)
>> "Return a task declaration.
>>
>> TASK is a headline. INFO is a plist used as a communication
>> channel.
>>
>> All valid attributes from TASK are inserted. If TASK defines
>> a property \"task_id\" it will be used as the id for this task.
>> Otherwise it will use the ID property. If neither is defined
>> a unique id will be associated to it."
>>
>> [snip]
>>
>> #+end_quote
>>
>> However, my headlines are still using the Org-assigned values for this...
>>
>> #+begin_org
>>
>> * Project :taskjuggler_project:
>> SCHEDULED: <2013-03-01 Fri>
>> ** Technical :T:
>> :PROPERTIES:
>> :task_id: T
>> :END:
>> *** Sub task
>> :PROPERTIES:
>> :task_id: T1
>> :END:
>>
>> #+end_org
>>
>> This gets exported as:
>>
>> #+begin_tjp
>>
>> task technical "Technical" {
>> purge allocate
>> allocate jwhendy
>> task sub "Sub task" {
>> milestone
>> }
>> }
>>
>> #+end_tjp
>>
>> Variations:
>> - I also tried using =:task_id: "T"= to see if it needed to be in quotes
>> - Tried changing my drawer name to TASK_ID to check for case-sensitivity
>>
>> The results of both were the same. Is this something on my end or a
>> but in ox-taskjuggler.el?
>>
>>
>> Thanks,
>> John
>
>
> As a followup, within a section, the :depends: attribute is being
> correctly resolved, even though naming is incorrect. I've taken to
> giving each area a single letter task_id, such as:
>
> #+begin_org
> * Project
> ** Technical
> :PROPERTIES:
> :TASK_ID: T
> :END:
> *** Sub task
> :PROPERTIES:
> :task_id: T1
> :END:
> *** Sub task2
> *** Sub task
> :PROPERTIES:
> :task_id: T2
> :depends: T1
> :END:
>
> #+end_org
>
> That's resolving deps correctly, but not naming correctly:
>
> #+begin_tjp
>
> task sub "Sub task" {
> milestone
> }
> task sub_task2 "Sub task2" {
> depends !sub
> milestone
>
> #+end_tjp
>
> The problem with this is when depending on something outside of that
> particular subtask; the TJ syntax is to use =!= as the equivalent to a
> period with respect to directories. So to refer to a task in another
> bucket, you need to do something like =:depends: !!M.M1= to refer to
> the Milestone bucket (task_id = M), subtask M1 task.
>
> This isn't working with Org taskjuggler export. Not being able to name
> task is a huge inconvenience, as one has to use Org's unique-id naming
> function, which I'd prefer not to do. It's easier (at least for me) to
> just unfold all the property drawers and refer to things by their two
> character id. I also tagged each top headline with it's letter bucket
> ":T:" so that I can just count the item order in the list for it's
> resulting subtask id (e.g. "T2").
>
>
> Best regards,
> John
Last addendum. I think this is what's going on:
- ox-taskjuggler will use task_id var for dependencies, but not the
actual task_id
- thus, it's resolving my dependencies (within a sub-task bucket), but
not using the actual names
Here's how unique-ids are assigned:
#+begin_src ox-taskjuggler.el
(defun org-taskjuggler-assign-task-ids (tasks info)
"Assign a unique ID to each task in TASKS.
TASKS is a list of headlines. Return value is an alist between
headlines and their associated ID. IDs are hierarchical, which
means they only need to be unique among the task siblings."
(let* (alist
(build-id
(lambda (tasks local-ids)
(org-element-map tasks 'headline
(lambda (task)
(let ((id (org-taskjuggler--build-unique-id task local-ids)))
(push id local-ids)
(push (cons task id) alist)
(funcall build-id (org-element-contents task) nil)))
info nil 'headline))))
(funcall build-id tasks nil)
alist))
#+end_src
Nothing related to task_id. That's calling this, which just makes sure
the initially parsed list is actually unique, and does some syntax
tweaking to make sure things work for what taskjuggler expects for
task_id syntax:
#+begin_src ox-taskjuggler.el
(defun org-taskjuggler--build-unique-id (item unique-ids)
"Return a unique id for a given task or a resource.
ITEM is an `headline' type element representing the task or
resource. Its id is derived from its name and made unique
against UNIQUE-IDS. If the (downcased) first token of the
headline is not unique try to add more (downcased) tokens of the
headline or finally add more underscore characters (\"_\")."
(let* ((parts (org-split-string (org-element-property :raw-value item)))
(id (org-taskjuggler--clean-id (downcase (pop parts)))))
;; Try to add more parts of the headline to make it unique.
(while (and (car parts) (member id unique-ids))
(setq id (concat id "_"
(org-taskjuggler--clean-id (downcase (pop parts))))))
;; If it's still not unique, add "_".
(while (member id unique-ids)
(setq id (concat id "_")))
id))
#+end_src
But later on, the function =(defun
org-taskjuggler-resolve-dependencies (task info)= will use task_id
property values to resolve deps!?
My suggestion (similar to the :start: property definition for a top
project headline before) would be to use task_id as the actual ID
/unless/ one isn't provided. Then assign the unique variable
definition for Orgmode. Better behavior would involve just passing the
depends value straight through to the .tjp file and letting
TaskJuggler resolve it.
So far, I find most errors on TJ compilation anyway, not via Org... so
that seems fine for now. Down the road, I'd love to see compilation of
the .tjp included in this, and errors could be made known the same way
LaTeX compilation errors appear.
John
next prev parent reply other threads:[~2013-04-01 0:44 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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+M2ft80S5XXv9JtRjQxNXoJ5FawHkmjSTU806Je-CyR-VcDdA@mail.gmail.com \
--to=jw.hendy@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).