Re: org-depend: dependencies between TODO entries in different files

[Karl Voit <devnull@Karl-Voit.at>]

* Carsten Dominik <dominik@uva.nl> wrote:
>
> Dear all,

Hi Carsten,

> Since ord-depend was only proof of concept, we could also think a bit more
> broadly about what it should be able to do.  Is there specific
> functionality it also should support, besides the TRIGGER/BLOCKER functions
> it has right now?

Oh my goodness - free wishes for org-depend? Christmas is rather
early this year! ;-)

OK, let's do some brain storming ...

For reference purposes: http://orgmode.org/worg/org-contrib/org-depend.html

> One issue to deal with is, that in different files, a different set of TODO
> keywords might be active, so if a TRIGGER entry changes a TODO state, and
> that entry lives in a different file, it falls onto the user to make sure
> that the required state is valid in both files.

From my point of view: due to the fact that the user has to state
the TRIGGER keyword manually, it is up to the user that this makes
any sense. So far, nothing prevents me from typing:

    :TRIGGER: foo-bar(INVALIDSTATUS)


> Any ides what is missing or might be useful?

Well, this comes a bit unprepared (I might be able to come up with
more feature possibilities to org-depend when thinking about it) but
I'd say that following workflows would be nice to discuss about:


Being able to specify SCHEDULED-dates *and* next status for
arbitrary IDs.

For example:

    ** NEXT Asking the client about XY
    :PROPERTIES:
    :TRIGGER: send-task(NEXT,2016-12-23)
    :END:
    
    ** Send XY to client
    :PROPERTIES:
    :ID: send-task
    :END:

Well the syntax might be chosen differently. What I want to achieve
is that when changing the "Asking" task to a finished state, the
"Send" task gets a fixed SCHEDULED value and the status NEXT. 

Additional: the two tasks are not necessarily in the same file or
within the same sub-hierarchy. So the «inherit scheduled date»
feature via chain-siblings-scheduled does not work in most cases to
me.


Another one:

    ** NEXT Asking the client about XY
    SCHEDULED: <2016-12-12>
    :PROPERTIES:
    :TRIGGER: send-task(NEXT,.+3d)
    :END:
    
    ** Send XY to client
    :PROPERTIES:
    :ID: send-task
    :END:

When the "Asking" task is set to a finished state, the "Send" task
will be scheduled three days in the future and gets the status NEXT.

The usual date-syntax applies here as well: +3d (3 days from maybe
the SCHEDULED(?) date of the "Asking" task), .+3d (3 days from now),
and so forth.


Another one: having the possibility to define "Send" state changes
that rely on the "Asking" state. For example: If I cancel the
"Asking" task, the "Send" state should be cancelled as well because
it makes no sense without the first one.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github