Previous: , Up: TODO extensions   [Contents][Index]

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 (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: , Up: TODO extensions   [Contents][Index]