emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bernt Hansen <bernt@norang.ca>
To: Marcel van der Boom <marcel@hsdev.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Subtasks are blocked in todo-items of ordered projects. Bug?
Date: Mon, 20 Jun 2011 19:37:29 -0400	[thread overview]
Message-ID: <87fwn4f51i.fsf@norang.ca> (raw)
In-Reply-To: <20110620155011.5fe773ea@hsdev.com> (Marcel van der Boom's message of "Mon, 20 Jun 2011 15:50:11 +0200")

Marcel van der Boom <marcel@hsdev.com> writes:

> Hi all,
>
> I've run into an annoyance wrt the :ORDERED: property and the blocking
> of tasks due to it.
>
> Here is the minimal usecase:
>
> --- 
> * TODO Project like header, containing subtasks
>   :PROPERTIES:
>   :ORDERED:  t
>   :END: 
> ** TODO This item is the first to be done in the project
>    This one is not blocked, as I expect.

ok

> ** TODO Next task with subtasks
>    This is blocked by the sibling above, which is what I expect 

ok

> *** TODO Subtask of a blocked sibling.
>     This seems to be blocked and I can't understand why. Marking it DONE would not mark the parent
>     done (neither explicit nor implicit). Why is it blocked then? Bug?

This is blocked until you mark the first level 2 TASK as DONE.  The
entire subtree is blocked by the previous incomplete task.

> *** TODO Second item in the blocked
>     This is also blocked, which could be right, because the parent
>     project has an ordered property and the sibling above is not yet
>     complete. 
> ---
>
> Should the first task in a subproject of a project
> having the ':ORDERED:' property set to true be blocked from marking
> 'DONE'? If so, why?

I think the answer is yes it should be blocked because the entire tree
is blocked - the previous task needs to be DONE first.  When the subtree
is unblocked you can then complete the first task in the subtree.

-Bernt

>
> The above minimal case is easy, but it's far from trivial to see why
> tasks in projects are blocked if the project is longer and has more
> outline levels.
>
> My expectation of the ordered property would be that it only acted
> one-level deep, regarded from a 'block-or-not' standpoint. 
>
> Thoughts?

-- 
Bernt

  reply	other threads:[~2011-06-20 23:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-20 13:50 Subtasks are blocked in todo-items of ordered projects. Bug? Marcel van der Boom
2011-06-20 23:37 ` Bernt Hansen [this message]
2011-06-21  8:59   ` Marcel van der Boom
2011-06-21 11:15     ` Memnon Anon
2011-06-21 11:30     ` Bernt Hansen
2011-06-21 11:40       ` Marcel van der Boom
2011-06-21 11:54         ` Carsten Dominik
2011-06-21 12:22           ` Carsten Dominik
2011-06-21 13:48         ` [PATCH] " Marcel van der Boom

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=87fwn4f51i.fsf@norang.ca \
    --to=bernt@norang.ca \
    --cc=emacs-orgmode@gnu.org \
    --cc=marcel@hsdev.com \
    /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).