From c4710ef172b4b628ac2a38cbbe6ff589a20dc622 Mon Sep 17 00:00:00 2001 From: Elian Doran Date: Thu, 30 Oct 2025 09:42:13 +0200 Subject: [PATCH] Updated Promoted attributes (markdown) --- Promoted attributes.md | 31 ------------------------------- Promoted-attributes.md | 1 + 2 files changed, 1 insertion(+), 31 deletions(-) delete mode 100644 Promoted attributes.md create mode 100644 Promoted-attributes.md diff --git a/Promoted attributes.md b/Promoted attributes.md deleted file mode 100644 index e6a1cd9..0000000 --- a/Promoted attributes.md +++ /dev/null @@ -1,31 +0,0 @@ -Promoted attributes are [[attributes|Attributes]] which are considered important and thus are "promoted" onto the main note UI. See example below: - -[[images/promoted-attributes.png]] - -You can see the note having kind of form with several fields. Each of these is just regular attribute, the only difference is that they appear on the note itself. - -Attributes can be pretty useful since they allow for querying and script automation etc. but they are also inconveniently hidden. This allows you to select few of the important ones and push them to the front of the user. - -Now, how do we make attribute to appear on the UI? - -## Attribute definition - -Attribute is always name-value pair where both name and value are strings. - -*Attribute definition* specifies how should this value be interpreted - is it just string, or is it a date? Should we allow multiple values or note? And importantly, should we *promote* the attribute or not? - -[[images/attribute-definitions.png]] - -You can notice tag attribute definition. These "definition" attributes define how the "value" attributes should behave. - -So there's one attribute for value and one for definition. But notice how definition attribute is [[Inheritable|Attribute inheritance]], meaning that it's also applied to all descendant note. So in a way, this definition is used for the whole subtree while "value" attributes are applied only for this note. - -### Inverse relation - -Some relations always occur in pairs - my favorite example is on the family. If you have a note representing husband and note representing wife, then there might be a relation between those two of `isPartnerOf`. This is bidirectional relationship - meaning that if a relation is pointing from husband to wife then there should be always another relation pointing from wife to husband. - -Another example is with parent - child relationship. Again these always occur in pairs, but in this case it's not exact same relation - the one going from parent to child might be called `isParentOf` and the other one going from child to parent might be called `isChildOf`. - -Relation definition allows you to specify such "inverse relation" - for the relation you just define you specify which is the inverse relation. Note that in the second example we should have two relation definitions - one for `isParentOf` which defines `isChildOf` as inverse relation and then second relation definition for `isChildOf` which defines `isParentOf` as inverse relation. - -What this does internally is that whenever we save a relation which has defined inverse relation, we check that this inverse relation exists on the relation target note. Similarly, when we delete relation, we also delete inverse relation on the target note. diff --git a/Promoted-attributes.md b/Promoted-attributes.md new file mode 100644 index 0000000..8cee7fb --- /dev/null +++ b/Promoted-attributes.md @@ -0,0 +1 @@ +See https://docs.triliumnotes.org/user-guide/advanced-usage/attributes/promoted-attributes. \ No newline at end of file