org: TODO dependencies
5.2.7 TODO dependencies
-----------------------
The structure of Org files (hierarchy and lists) makes it easy to define
TODO dependencies. Usually, a parent TODO task should not be marked
DONE until all subtasks (defined as children tasks) are marked as DONE.
And sometimes there is a logical sequence to a number of (sub)tasks, so
that one task cannot be acted upon before all siblings above it are
done. If you customize the option ‘org-enforce-todo-dependencies’, Org
will block entries from changing state to DONE while they have children
that are not DONE. Furthermore, if an entry has a property ‘ORDERED’,
each of its children will be blocked until all earlier siblings are
marked DONE. Here is an example:
* TODO Blocked until (two) is done
** DONE one
** TODO two
* Parent
:PROPERTIES:
:ORDERED: t
:END:
** TODO a
** TODO b, needs to wait for (a)
** TODO c, needs to wait for (a) and (b)
‘C-c C-x o (org-toggle-ordered-property)’
Toggle the ‘ORDERED’ property of the current entry. A property is
used for this behavior because this should be local to the current
entry, not inherited like a tag. However, if you would like to
track the value of this property with a tag for better visibility,
customize the option ‘org-track-ordered-property-with-tag’.
‘C-u C-u C-u C-c C-t’
Change TODO state, circumventing any state blocking.
If you set the option ‘org-agenda-dim-blocked-tasks’, TODO entries
that cannot be closed because of such dependencies will be shown in a
dimmed font or even made invisible in agenda views (Agenda
Views).
You can also block changes of TODO states by looking at checkboxes
(Checkboxes). If you set the option
‘org-enforce-todo-checkbox-dependencies’, an entry that has unchecked
checkboxes will be blocked from switching to DONE.
If you need more complex dependency structures, for example
dependencies between entries in different trees or files, check out the
contributed module ‘org-depend.el’.