Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
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 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
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On Jun 21, 2011, at 1:40 PM, Marcel van der Boom wrote: > > On di 21-jun-2011 07:30 > Bernt Hansen 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
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On di 21-jun-2011 07:30 Bernt Hansen 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 smime.p7s Description: S/MIME cryptographic signature
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
Marcel van der Boom writes: > On ma 20-jun-2011 19:37 > Bernt Hansen 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
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
Marcel van der Boom 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
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On ma 20-jun-2011 19:37 Bernt Hansen 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 smime.p7s Description: S/MIME cryptographic signature
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
Marcel van der Boom 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
[O] Subtasks are blocked in todo-items of ordered projects. Bug?
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 smime.p7s Description: S/MIME cryptographic signature
