emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Setting taskjuggler project start date (ox-taskjuggler)


From: John Hendy
Subject: Re: [O] Setting taskjuggler project start date (ox-taskjuggler)
Date: Mon, 25 Mar 2013 02:30:06 -0500

On Mon, Mar 25, 2013 at 2:17 AM, John Hendy <address@hidden> wrote:
> On Mon, Mar 25, 2013 at 1:27 AM, John Hendy <address@hidden> wrote:
>> Having trouble setting the project start date, which results in a
>> build error since my project started before today, and the default
>> project start appears to be today's date. This was with no
>> customization to the top level headline. Intuitively, I added a
>> :start: property like so:
>>
>> #+begin_src org
>>
>> * Project                                               :taskjuggler_project:
>>   :PROPERTIES:
>>   :start:    2013-03-01
>>   :END:
>>
>> #+end_src
>>
>> This results in (no change from exporting with no :start: property:
>>
>> #+begin_src TJ
>>
>> project nil "Project" "1.0" 2013-03-25 +280d {
>> }
>>
>> #+end_src
>>
>> From digging around in ox-taskjuggler.el, it looks like the project
>> gets defined here:
>>
>> #+begin_src ox-taskjuggler.el (line 607)
>>
>> (defun org-taskjuggler--build-project (project info)
>>   "Return a project declaration.
>> PROJECT is a headline.  INFO is a plist used as a communication
>> channel.  If no start date is specified, start today.  If no end
>> date is specified, end `org-taskjuggler-default-project-duration'
>> days from now."
>>   (format "project %s \"%s\" \"%s\" %s %s {\n}\n"
>>           (org-taskjuggler-get-id project info)
>>           (org-taskjuggler-get-name project)
>>           ;; Version is obtained through :TASKJUGGLER_VERSION:
>>           ;; property or `org-taskjuggler-default-project-version'.
>>           (or (org-element-property :VERSION project)
>>               org-taskjuggler-default-project-version)
>>           (or (org-taskjuggler-get-start project)
>>               (format-time-string "%Y-%m-%d"))
>>           (let ((end (org-taskjuggler-get-end project)))
>>             (or (and end (format "- %s" end))
>>                 (format "+%sd" org-taskjuggler-default-project-duration)))))]
>>
>> #+end_src
>>
>> I'm no esliper, but I think I can track that the consecutive =%s=
>> arguments are replaced by the successive function calls. That, and
>> =org-taskjuggler-get-start project= looks like the ticket. That
>> function is here:
>>
>> #+begin_src ox-taskjuggler.el (line 372)
>>
>> (defun org-taskjuggler-get-start (item)
>>   "Return start date for task or resource ITEM.
>> ITEM is a headline.  Return value is a string or nil if ITEM
>> doesn't have any start date defined.."
>>   (let ((scheduled (org-element-property :scheduled item)))
>>     (and scheduled (org-timestamp-format scheduled "%Y-%02m-%02d"))))
>>
>> #+end_src
>>
>> So, that suggested that perhaps I needed to use :scheduled: instead of
>> :start:. I tried that with the same results. It appears that this
>> property /is/ applied at the task level for the top headline, however:
>>
>> #+begin_src TJ
>>
>> task project "Project" {
>>   purge allocate
>>   allocate jwhendy
>>   start 2013-03-01
>> ...
>>
>> }
>>
>> #+end_src
>>
>> So, it applies :start: to the top level project in the /task/
>> definition area, but doesn't apply it to the very top level project
>> definition.
>>
>> Any suggestions?
>
> This works, though I know approximately nil (didja see what I did
> there) about elisp:
>
> #+begin_src ox-taskjuggler.el
>
> (defun org-taskjuggler--build-project (project info)
>   "Return a project declaration.
> PROJECT is a headline.  INFO is a plist used as a communication
> channel.  If no start date is specified, start today.  If no end
> date is specified, end `org-taskjuggler-default-project-duration'
> days from now."
>   (format "project %s \"%s\" \"%s\" %s %s {\n}\n"
>           (org-taskjuggler-get-id project info)
>           (org-taskjuggler-get-name project)
>           ;; Version is obtained through :TASKJUGGLER_VERSION:
>           ;; property or `org-taskjuggler-default-project-version'.
>           (or (org-element-property :VERSION project)
>               org-taskjuggler-default-project-version)
>           (or (org-element-property :START project)
>               (format-time-string "%Y-%02m-%02d"))
>           (let ((end (org-element-property :END project)))
>             (or (and end (format "- %s" end))
>                 (format "+%sd" org-taskjuggler-default-project-duration)))))
>
> #+end_src
>
> I don't know why the org-taskjuggler-get-start function works for the
> task definition and not the project definition... but just looking for
> the contents of the :start: and :end: properties directly is my
> current hack. I'll leave it like that just so I don't have to manually
> change the .tjp file at every export, but I'm sure there's a "proper"
> way to fix :)
>

Ah. org-taskjuggler-get-start /isn't/ working for the tasks... I've
just set them with :start: and that's a keyword that I think the
exporter is directly inserting. I don't think that function returns
anything at all... but for the build-project function, it has a backup
value of today's date (format-date-string).

Could it be as simple as the org-taskjuggler-get-start function
needing a capitalized org-element-property call?

Currently, it's:

(let ((scheduled (org-element-property :scheduled item)))

But the other calls to org-element-property have things like :VERSION.

I changed it in my file and did M-x org-reload and now this:

* Project                                               :taskjuggler_project:
  :PROPERTIES:
  :scheduled:      2014-01-01

Spits out this:

project nil "Project" "5" -001-11-30 +280d {
}

Making progress... but it's obviously not parsing the property
correctly... but at least there's evidence it's doing /something/ with
what I set for property.

I think I've narrowed this down to two things:
1) org-taskjuggler-get-start (and probably *-get-end) is not working properly
2) project applicable keywords stored in property drawer should be
being parsed, but they're not


That's about all I'm good for with my current elisp knowledge!


John



>
>
> John
>
>>
>>
>> John



reply via email to

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