Previous: Faces for TODO keywords, Up: TODO extensions [Contents][Index]
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)
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
.
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 (see Agenda Views).
You can also block changes of TODO states by looking at checkboxes
(see 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.
Previous: Faces for TODO keywords, Up: TODO extensions [Contents][Index]