Marcel van der Boom <mar...@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