# Operon inheritance rules Operon has three separate inheritance mechanisms, and it matters which one you are looking at. One copies fields from a parent, one carries fields forward when a recurring task rolls to its next run, and one borrows a parent's color and icon for display only. Parent fields are copied when creating a subtask and can optionally fill gaps when linking an existing task to a parent. They behave differently, so this page treats each on its own and then names the distinction that ties them together. Parent date-range expansion is related to the task tree, but it is a separate automation rather than a fourth kind of inheritance. > **MEDIA-DOCS-058-1:** A parent task and a new subtask side by side, with arrows showing which fields were copied and which were left blank. ## The three mechanisms at a glance | Mechanism | When it happens | Between whom | Copy or live | |---|---|---|---| | Parent to child | At subtask creation, or optionally when linking an existing task to a parent | Parent task to its child | One-time copy | | Recurrence carry-forward | When a recurring task completes | A completed occurrence to its successor | One-time copy | | Display inheritance | Every time a task bar renders | A task to its nearest ancestor | Live lookup | ## 1. Parent to child When you create a subtask, Operon copies a chosen set of the parent's fields into the new child once, at the moment of creation. This is a snapshot, not a live link: editing the parent later does not change a subtask that already exists. - The `parentTask` link itself is always added separately. It is the structural connection, not one of the inherited metadata fields. - **Default inherited fields:** `status`, `priority`, `taskIcon`, `taskColor`. - **You choose the list.** In **Settings → Operon → Tasks → Relationships**, the **Parent-Child task inheritance** setting decides which parent fields are copied into a new child. You can add or remove fields, including your own custom keys, and you can include tags. - **Status is special.** When `status` is inherited, the child does not copy the parent's exact stage. It starts at the *first* status of a pipeline. The **Status pipeline** setting decides which pipeline supplies that starting status: `Parent's pipeline` (the default) or `Default pipeline`. - **Priority** copies the parent's priority, or falls back to your default priority when the parent has none. Some fields can never be inherited, whatever the setting says, because they must stay unique or be recomputed: `operonId`, `parentTask`, `datetimeCreated`, `datetimeModified`, `blocking`, `blockedBy`, `duration`, `totalEstimate`, `totalDuration`, the subtask counts, `repeatSeriesId`, `repeatOccurrenceDate`, `reminderDatetimes`, `reminderRules`, `timezone`, `trackers`, `activeTracker`, and `related`. Reminders are on that list for a practical reason rather than a technical one: a subtask is rarely due when its parent is, so inheriting the parent's reminders would fire notifications about the wrong work at the wrong time. Give a subtask its own reminders when it needs them. See [Reminders](/docs/docs-116-reminders/). ### Linking an existing task to a parent Turn on **Inherit properties when linking a parent** in **Settings → Operon → Tasks → Relationships** to apply the configured inheritance fields when you assign a new or different parent to an existing task. The setting is **off by default**. This fills gaps rather than replacing your work. An empty single-value field can receive the parent's value; a field that already has a value keeps it. List fields and tags keep their existing items and add only missing inherited items. The same field exclusions and Status pipeline rule used for new subtasks still apply. For example, if a child already has Priority B and the parent has Priority A, the child keeps B. If Tags is selected for inheritance and the parent has a tag the child lacks, that tag is added alongside the child's existing tags. This happens once when the parent assignment changes. Choosing the same parent again does not reapply inheritance, removing the parent does not undo copied values, and later edits to the parent do not synchronize into the child. Turning on the setting does not backfill existing relationships. ## 2. Recurrence carry-forward (next occurrence) When a recurring task is completed, Operon generates the next occurrence and copies fields forward from the run you just finished. See [Recurring tasks](/docs/docs-033-recurring-tasks/). - **Carried forward** (intent and shape): `assignees`, `priority`, `status`, `contexts`, `parentTask`, `repeat`, `datetimeRepeatEnd`, `reminderRules`, `estimate`, `note`, `taskIcon`, `taskColor`, `dateStarted`, `dateDue`, and the timed block `datetimeStart` and `datetimeEnd` (the relative dates are shifted to the next occurrence). - **Reset** (the reality of one run): `dateCompleted`, `dateCancelled`, `duration`, `trackers`, `activeTracker`, `progress`, the subtask counts, `totalEstimate`, and `totalDuration`. Dependencies (`blocking`, `blockedBy`) are not carried forward either. - **Fresh each time:** a new `operonId`, a new `datetimeCreated`, the next `dateScheduled`, and an updated `datetimeModified`. The two reminder fields intentionally behave differently. **ReminderRules carry forward** because they describe a relationship, such as 15 minutes before Start time; Operon resolves that same rule against the new occurrence's shifted dates when the referenced date is available. **ReminderDatetimes do not carry forward** because they are fixed moments that belong to the occurrence where you created them. See [Reminders](/docs/docs-116-reminders/). ## 3. Display inheritance (color and icon) For display only, a task with no color or icon of its own borrows from its ancestors. If `taskColor` or `taskIcon` is blank, Operon walks up the `parentTask` chain and uses the nearest ancestor that has a value. This affects what the inline task bar shows, not what is stored on the task. This lookup is live. It is resolved every time the bar renders, so changing an ancestor's color updates how a colorless descendant looks right away. The walk is bounded, so a long or broken chain cannot stall rendering. > **MEDIA-DOCS-058-2:** Inheritance rules. ![MEDIA-DOCS-058-2 - Inheritance rules](/assets/docs/media/MEDIA-DOCS-058-2.png?v=1702807484b5) ## Copy versus live: the key distinction Mechanisms 1 and 2 write values at one moment: when creating a task, linking a different parent with the option enabled, or generating the next occurrence. Mechanism 3 writes nothing and borrows the value at render time. That is why changing a parent's priority does not touch a subtask you already made, while changing a parent's color does change how a colorless child appears. ## Parent date expansion is relationship automation The optional **Automatically expand parent task date range** setting works on tasks that already exist. It reads the dates across a parent's descendant tree and can move the parent's Start Date earlier or Due Date later when the tree extends beyond the current range. It never copies those parent dates into a child, and it never contracts the range when descendants move inward. That makes it relationship automation, not inheritance: the task tree causes an ongoing aggregate update to the parent. See [Parent and sub-tasks](/docs/docs-016-parent-and-sub-tasks/) for the dates used and the deletion behavior that keeps the tree connected safely. ## FAQ **I changed the parent after creating a subtask. Did the subtask update?** Not for copied metadata like status or priority, which were taken once at creation. Yes for displayed color and icon, if the child has none of its own. **Why did my new subtask start at the first status instead of the parent's stage?** Inherited status always starts at the first status of a pipeline, not the parent's exact status. **Can I turn off parent to child inheritance?** Yes. Clear the Parent-Child task inheritance list in settings. The parent link is still added; no metadata is copied. To keep inheritance for new subtasks but not for existing tasks, leave **Inherit properties when linking a parent** off. **Can custom fields be inherited?** Yes, as long as they are not internal. Add them to the inheritance list. **Is automatic parent date expansion another inherited field?** No. It is an optional ongoing relationship automation that widens existing parent dates from descendant dates; it does not copy a parent value into a child. ## Settings Operon settings for this live in **Settings → Operon → Tasks → Relationships**. The **Parent-Child task inheritance** section contains **Status pipeline** and the inherited-field selection. The separate **Relationships** section contains **Inherit properties when linking a parent** and relationship automation such as parent date-range expansion. ## Related - [Operon Docs MOC](/docs/docs-001-operon-docs-moc/) - [Parent and sub-tasks](/docs/docs-016-parent-and-sub-tasks/) - [Task properties](/docs/docs-018-task-properties/) - [Pipelines and statuses](/docs/docs-037-pipelines-and-statuses/) - [Reminders](/docs/docs-116-reminders/)