emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Subtasks are blocked in todo-items of ordered projects. Bug?
@ 2011-06-20 13:50 Marcel van der Boom
  2011-06-20 23:37 ` Bernt Hansen
  0 siblings, 1 reply; 9+ messages in thread
From: Marcel van der Boom @ 2011-06-20 13:50 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

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.
** TODO Next task with subtasks
   This is blocked by the sibling above, which is what I expect 
*** 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?
*** 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?

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?

marcel


-- 
Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
HS-Development BV    -- http://www.hsdev.com
We use bitcoin!      -- http://bitcoin.org

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5618 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  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
  2011-06-21  8:59   ` Marcel van der Boom
  0 siblings, 1 reply; 9+ messages in thread
From: Bernt Hansen @ 2011-06-20 23:37 UTC (permalink / raw)
  To: Marcel van der Boom; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  2011-06-20 23:37 ` Bernt Hansen
@ 2011-06-21  8:59   ` Marcel van der Boom
  2011-06-21 11:15     ` Memnon Anon
  2011-06-21 11:30     ` Bernt Hansen
  0 siblings, 2 replies; 9+ messages in thread
From: Marcel van der Boom @ 2011-06-21  8:59 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]


On ma 20-jun-2011 19:37
Bernt Hansen <bernt@norang.ca> wrote:

>> 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.

Ok, to get the behaviour I want, I could remove the 'TODO' keyword
from the subproject. 

That will allow me to work on the subitems in parallel.  Obvious
disadvantage is that the subproject as such can only have a
'count' or 'percentage' but not a 'state' and thus cannot be tracked
anymore.

Any other suggestions for a way to work on subitems in parallel with the
'main tasks'?  I'll spent some time digging if the wanted
behaviour could be formulated as an option to set without disturbing
the default behaviour. 

marcel


-- 
Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
HS-Development BV    -- http://www.hsdev.com
We use bitcoin!      -- http://bitcoin.org

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5618 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  2011-06-21  8:59   ` Marcel van der Boom
@ 2011-06-21 11:15     ` Memnon Anon
  2011-06-21 11:30     ` Bernt Hansen
  1 sibling, 0 replies; 9+ messages in thread
From: Memnon Anon @ 2011-06-21 11:15 UTC (permalink / raw)
  To: emacs-orgmode

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

[...]
> That will allow me to work on the subitems in parallel.  Obvious
> disadvantage is that the subproject as such can only have a
> 'count' or 'percentage' but not a 'state' and thus cannot be tracked
> anymore.
>
> Any other suggestions for a way to work on subitems in parallel with the
> 'main tasks'?

Strictly speaking, there is no "parallel" working on subitems or tasks
in an ordered Tree; thats why I only use it for situations where there
is really no alternative order than the way it is laid out in front of
me.

Did you try org-depend.el in contrib/ ?
It offers a much more flexibel way of handling dependencies.
OTOH, this flexibility naturally needs more manual intervention to set
things up than `C-c C-x o'.

Memnon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  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
  1 sibling, 1 reply; 9+ messages in thread
From: Bernt Hansen @ 2011-06-21 11:30 UTC (permalink / raw)
  To: Marcel van der Boom; +Cc: emacs-orgmode

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

> On ma 20-jun-2011 19:37
> Bernt Hansen <bernt@norang.ca> wrote:
>
>>> 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.
>
> Ok, to get the behaviour I want, I could remove the 'TODO' keyword
> from the subproject. 
>
> That will allow me to work on the subitems in parallel.  Obvious
> disadvantage is that the subproject as such can only have a
> 'count' or 'percentage' but not a 'state' and thus cannot be tracked
> anymore.
>
> Any other suggestions for a way to work on subitems in parallel with the
> 'main tasks'?  I'll spent some time digging if the wanted
> behaviour could be formulated as an option to set without disturbing
> the default behaviour. 

You can work on things in parallel - you just can't mark them as
completed.  I clock in time on tasks I work on which changes TODO to
STARTED and there is no restriction (that I'm aware of) on doing this.

You can also force the task state to DONE with a triple prefix (C-u C-u
C-u C-c C-t d) which will ignore the blocking rules for this state
change.

HTH,
-- 
Bernt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  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 13:48         ` [PATCH] " Marcel van der Boom
  0 siblings, 2 replies; 9+ messages in thread
From: Marcel van der Boom @ 2011-06-21 11:40 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]


On di 21-jun-2011 07:30
Bernt Hansen <bernt@norang.ca> wrote:

> You can also force the task state to DONE with a triple prefix (C-u
> C-u C-u C-c C-t d) which will ignore the blocking rules for this state
> change.
I think I'll use this, sounds the simplest for my usecase.

Thanks,

marcel

-- 
Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
HS-Development BV    -- http://www.hsdev.com
We use bitcoin!      -- http://bitcoin.org

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5618 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  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
  1 sibling, 1 reply; 9+ messages in thread
From: Carsten Dominik @ 2011-06-21 11:54 UTC (permalink / raw)
  To: Marcel van der Boom; +Cc: Bernt Hansen, emacs-orgmode


On Jun 21, 2011, at 1:40 PM, Marcel van der Boom wrote:

> 
> On di 21-jun-2011 07:30
> Bernt Hansen <bernt@norang.ca> wrote:
> 
>> You can also force the task state to DONE with a triple prefix (C-u
>> C-u C-u C-c C-t d) which will ignore the blocking rules for this state
>> change.

And one more alternative:

If `org-treat-insert-todo-heading-as-state-change' is nil (which is the default),
S-right on a TODO keyword will change states and bypass both logging and blocking.

Cheers

- Carsten

> I think I'll use this, sounds the simplest for my usecase.
> 
> Thanks,
> 
> marcel
> 
> -- 
> Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
> HS-Development BV    -- http://www.hsdev.com
> We use bitcoin!      -- http://bitcoin.org

- Carsten

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subtasks are blocked in todo-items of ordered projects. Bug?
  2011-06-21 11:54         ` Carsten Dominik
@ 2011-06-21 12:22           ` Carsten Dominik
  0 siblings, 0 replies; 9+ messages in thread
From: Carsten Dominik @ 2011-06-21 12:22 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode, Bernt Hansen


On Jun 21, 2011, at 1:54 PM, Carsten Dominik wrote:

> 
> On Jun 21, 2011, at 1:40 PM, Marcel van der Boom wrote:
> 
>> 
>> On di 21-jun-2011 07:30
>> Bernt Hansen <bernt@norang.ca> wrote:
>> 
>>> You can also force the task state to DONE with a triple prefix (C-u
>>> C-u C-u C-c C-t d) which will ignore the blocking rules for this state
>>> change.
> 
> And one more alternative:
> 
> If `org-treat-insert-todo-heading-as-state-change' is nil (which is the default),
> S-right on a TODO keyword will change states and bypass both logging and blocking.

this was a typo.  I meant the variable 
`org-treat-S-cursor-todo-selection-as-state-change', and its default is t, so
you have to set it to zero to get the behavior I was describing....

- Carsten

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Subtasks are blocked in todo-items of ordered projects. Bug?
  2011-06-21 11:40       ` Marcel van der Boom
  2011-06-21 11:54         ` Carsten Dominik
@ 2011-06-21 13:48         ` Marcel van der Boom
  1 sibling, 0 replies; 9+ messages in thread
From: Marcel van der Boom @ 2011-06-21 13:48 UTC (permalink / raw)
  To: Marcel van der Boom; +Cc: Bernt Hansen, emacs-orgmode


[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]


On di 21-jun-2011 13:40
Marcel van der Boom <marcel@hsdev.com> wrote:

>> You can also force the task state to DONE with a triple prefix (C-u
>> C-u C-u C-c C-t d) which will ignore the blocking rules for this
>> state change.  
> I think I'll use this, sounds the simplest for my usecase.

On second thought, the patch is quite minimal, I've applied the
attached patch in my branch which seems to do what I want. 

I'd obviously welcome this being applied in the main tree, but I can
understand if it won't. What would be nice in general if the message
that is produced contained a hint on why the entry was blocked by the
system (children incomplete, sibling blocked etc.)

Thanks everyone for the help.

marcel

-- 
Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
HS-Development BV    -- http://www.hsdev.com
We use bitcoin!      -- http://bitcoin.org

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: block-ignore-ancestor-siblings.patch --]
[-- Type: text/x-patch, Size: 1492 bytes --]

diff --git a/lisp/org.el b/lisp/org.el
index fee3174..c28d355 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2181,6 +2181,17 @@ to change is while Emacs is running is through the customize interface."
   :group 'org-todo
   :type 'boolean)
 
+(defcustom org-blocker-ignore-ancestor-siblings nil
+  "Non-nil means that when determining if a TODO entry is blocked,
+siblings of entries which are higher up the hierarchy are not
+considered. This allows to register state changes for item in
+subprojects of ordered projects which enforce ordering. The
+subproject itself is not affected. See
+`org-block-todo-from-children-or-siblings-or-parent' for the
+implementation."
+  :group 'org-todo
+  :type  'boolean) 
+
 (defcustom org-enforce-todo-checkbox-dependencies nil
   "Non-nil means unchecked boxes will block switching the parent to DONE.
 When this is nil, checkboxes have no influence on switching TODO states.
@@ -11151,7 +11162,8 @@ changes.  Such blocking occurs when:
 	    (when (and (org-not-nil (org-entry-get (point) "ORDERED"))
 		       (forward-line 1)
 		       (re-search-forward org-not-done-heading-regexp pos t))
-	      (throw 'dont-block nil)))))))) ; block, older sibling not done.
+	      ; block, older sibling not done, unless configured to ignore.
+	      (throw 'dont-block org-blocker-ignore-ancestor-siblings)))))))) 
 
 (defcustom org-track-ordered-property-with-tag nil
   "Should the ORDERED property also be shown as a tag?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5618 bytes --]

^ permalink raw reply related	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-06-21 13:49 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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).