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? John
On Mon, Mar 25, 2013 at 1:27 AM, John Hendy <jw.hendy@gmail.com> 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 :) John > > > John
On Mon, Mar 25, 2013 at 2:17 AM, John Hendy <jw.hendy@gmail.com> wrote: > On Mon, Mar 25, 2013 at 1:27 AM, John Hendy <jw.hendy@gmail.com> 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
Hello,
John Hendy <jw.hendy@gmail.com> writes:
> 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!
Did you try to set a schedule for the task at the root of the project
(with C-c C-s)?
`org-taskjuggler-get-start' expects a SCHEDULED: <...> line below the
headline.
Regards,
--
Nicolas Goaziou
On Mon, Mar 25, 2013 at 3:15 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > Hello, > > John Hendy <jw.hendy@gmail.com> writes: > >> 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! > > Did you try to set a schedule for the task at the root of the project > (with C-c C-s)? > > `org-taskjuggler-get-start' expects a SCHEDULED: <...> line below the > headline. No. Unfortunately, though obvious now, it evaded me that =scheduled= needed an orgmode time stamp. If you have =org-taskjuggler-keep-project-as-task=, it will take the :start: property and use this in the project-as-top-level-task output. Could this be used after =scheduled= and before defaulting to today's date? This would seem to unify the syntax. It strikes me as reasonable to take 1) scheduled, 2) :start: in property drawer and 3) default to today's date (in that order). What do you think? I didn't see this mentioned at the tutorial: - http://orgmode.org/worg/org-tutorials/org-taskjuggler.html I'm writing an updated version for tj3, so I'll include this. Thanks! John > > > Regards, > > -- > Nicolas Goaziou
Hello,
John Hendy <jw.hendy@gmail.com> writes:
> If you have =org-taskjuggler-keep-project-as-task=, it will take the
> :start: property and use this in the project-as-top-level-task output.
> Could this be used after =scheduled= and before defaulting to today's
> date? This would seem to unify the syntax.
>
> It strikes me as reasonable to take 1) scheduled, 2) :start: in
> property drawer and 3) default to today's date (in that order).
>
> What do you think?
I don't know much about TaskJuggler. It doesn't sound unreasonable to
me, but I'd rather let Christian Egli (Cc'ed) decide about it.
Regards,
--
Nicolas Goaziou
On Wed, Mar 27, 2013 at 9:37 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: > Hello, > > John Hendy <jw.hendy@gmail.com> writes: > >> If you have =org-taskjuggler-keep-project-as-task=, it will take the >> :start: property and use this in the project-as-top-level-task output. >> Could this be used after =scheduled= and before defaulting to today's >> date? This would seem to unify the syntax. >> >> It strikes me as reasonable to take 1) scheduled, 2) :start: in >> property drawer and 3) default to today's date (in that order). >> >> What do you think? > > I don't know much about TaskJuggler. It doesn't sound unreasonable to > me, but I'd rather let Christian Egli (Cc'ed) decide about it. Sure. The gist is that you define a "range" for the overall project. My issue probably stems from the fact that I'm using the functionality simply for the organizational aspects of Org-mode vs. writing all that TJ code manually. I *haven't* (so far) been actually using TODOs or SCHEDULED/DEADLINEs on my headers, which may be why I was surprised at the functionality. I'm more using the property drawers to just manually access the keywords allowed via the TJ syntax. Since others might be doing this (and the tutorial doesn't suggest to use Org-mode scheduling functionality)... might be good to at least allow for it. Also, since I noticed that my tasks pick up the :start: property and that the get-start (item) function *could* pick up a scheduled date as well... might be good to anticipate the case in which the user specifies both (probably accidentally). Maybe just provide an error that either scheduled/deadline *or* :start: should be used, but not both. Or if scheduled date conflicts with an duration/dependency relationship as well? Some of this might be handled by the tj3 command on the resultant .tjp file, though. I've found that the export is pretty strict and it will with most cases like this. Thanks! John > > > Regards, > > -- > Nicolas Goaziou
John Hendy <jw.hendy@gmail.com> writes: > On Wed, Mar 27, 2013 at 9:37 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote: >> Hello, >> >> John Hendy <jw.hendy@gmail.com> writes: >> >>> If you have =org-taskjuggler-keep-project-as-task=, it will take the >>> :start: property and use this in the project-as-top-level-task output. >>> Could this be used after =scheduled= and before defaulting to today's >>> date? This would seem to unify the syntax. >>> >>> It strikes me as reasonable to take 1) scheduled, 2) :start: in >>> property drawer and 3) default to today's date (in that order). I just pushed a change that should implement this the way you describe above. > Also, since I noticed that my tasks pick up the :start: property and > that the get-start (item) function *could* pick up a scheduled date as > well... might be good to anticipate the case in which the user > specifies both (probably accidentally). Maybe just provide an error > that either scheduled/deadline *or* :start: should be used, but not > both. Currently the org-taskjuggler-get-start function is only used to determine the start of a project or when checking if a task is a milestone (ie has neither a start nor an end), so the problem above is independent of that. But yes it is a problem: if you schedule a task and add a start attribute you will most likely have two start attributes for that task in your tjp file and the tj3 compilation will fail. Wouldn't this be sufficient? > Or if scheduled date conflicts with an duration/dependency > relationship as well? What do you mean? This to me sounds like it's the job of tj3. > Some of this might be handled by the tj3 command on the resultant .tjp > file, though. Yes, my sentiments exactly :-) Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland