Describe the feature
Currently, the (inheritable) flag on a promoted attribute definition controls whether the definition itself propagates to descendant notes. There is no way to specify that the value label or relation created when a user fills in that field should also be stamped as inheritable.
This request proposes adding inheritable as a recognised property in the definition value string, applying to both #label: and #relation: definitions. This would cause any value attribute created via that promoted field to have isInheritable = true automatically.
Proposed syntax
#relation:client(inheritable)="promoted,single,text" <-- This already exists, so for all children the label/relation can be chosen independently
#relation:client="promoted,inheritable,single,text" <-- This is the proposed implementation so that the actual value in the label/relation is inherited by all children
The (inheritable) on the definition label continues to propagate the definition. The inheritable inside the value string is a new property that controls the isInheritable flag on the created value attribute.
Use case
A template is used across a set of notes that represent projects. Each note has a promoted ~client relation pointing to a client note. Child notes under each project note — such as location notes, meeting notes, or sub-tasks — should automatically inherit the ~client relation from their parent without requiring the user to re-set it or manually tick the inheritable flag on each owned attribute after filling it in.
The same use case applies to labels — e.g. a #Country label set on a parent trip note should propagate to all child location notes.
Current workaround
After filling in a promoted attribute value, the user must manually open the Owned Attributes panel and tick the inheritable flag on that specific attribute — for every note individually. There is no way to automate this without a custom script or ETAPI bulk-update.
Prior discussion
Discussion #4554 raises the same limitation and includes this observation: "it'd be great if a promoted label could have a checkbox or something next to it to control inheritability of the value it controls." This feature request formalises that as a syntax-level solution, consistent with how other definition properties (promoted, single, multi, alias=) are already expressed.
Describe the feature
Currently, the
(inheritable)flag on a promoted attribute definition controls whether the definition itself propagates to descendant notes. There is no way to specify that the value label or relation created when a user fills in that field should also be stamped as inheritable.This request proposes adding
inheritableas a recognised property in the definition value string, applying to both#label:and#relation:definitions. This would cause any value attribute created via that promoted field to haveisInheritable = trueautomatically.Proposed syntax
The
(inheritable)on the definition label continues to propagate the definition. Theinheritableinside the value string is a new property that controls theisInheritableflag on the created value attribute.Use case
A template is used across a set of notes that represent projects. Each note has a promoted
~clientrelation pointing to a client note. Child notes under each project note — such as location notes, meeting notes, or sub-tasks — should automatically inherit the~clientrelation from their parent without requiring the user to re-set it or manually tick the inheritable flag on each owned attribute after filling it in.The same use case applies to labels — e.g. a
#Countrylabel set on a parent trip note should propagate to all child location notes.Current workaround
After filling in a promoted attribute value, the user must manually open the Owned Attributes panel and tick the inheritable flag on that specific attribute — for every note individually. There is no way to automate this without a custom script or ETAPI bulk-update.
Prior discussion
Discussion #4554 raises the same limitation and includes this observation: "it'd be great if a promoted label could have a checkbox or something next to it to control inheritability of the value it controls." This feature request formalises that as a syntax-level solution, consistent with how other definition properties (
promoted,single,multi,alias=) are already expressed.