emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Item task_id not being used in taskjuggler export


From: John Hendy
Subject: Re: [O] Item task_id not being used in taskjuggler export
Date: Sun, 31 Mar 2013 19:44:18 -0500

On Sun, Mar 31, 2013 at 7:16 PM, John Hendy <address@hidden> wrote:
> On Sun, Mar 31, 2013 at 7:04 PM, John Hendy <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]