I would like to mention a bug in the Tinderbox software. When an email is imported (drag and drop) from Devonthink into Tinderbox, it is impossible to change the prototype, i.e. there is no change in attributes.
This doesnāt sound like a bug but rather an inheritance issue. Bby āattributesā I assume you refer to Key Attributes (KA). A note inherits the same Key Attributes (via $KeyAttributes) as its prototype unless the KA have been changed at note level. If the latter, changing the prototype will not change that noteās KA as the note has a local value for $KeyAttributes, although the noteās assigned prototype has actually changed.
Further to what @mwra mentions, if you want to revert the key attributes for a note to the prototypeās KA (i.e., override the local note settings that Mark discussed) there are a few ways. You could use a stamp, an agent, or simply open Quickstamp and click the button under ādefaultā. If there is a prototype assigned to that note, this action will revert the KA for that note to the prototypeās KAs
No bug. This is just the way inheritance works.
What does the arrow under āassigned to this noteā do? Iāve never understood that one.
The āassign thisā button under āassigned to this noteā lets you restore the current value.
Itās mostly useful if you started to edit a complicated string or action, things get fouled up, and you want to avoid changing the value at all.
Iāve just updated the aTbRef page on the Quickstamp Inspector. Basically the left buttonās label indicates one of two states: the doc default or, if a prototype is used, the prototypeās value. The right buttonās label indicates one of three states: doc default, inherited from prototype, or a locally set value.
Does this mean that prototypes cannot be normally applied to notes imported from DevonThink, unless all their filled $KeyAttributes are reset to default, so that their data is lost?
Itās not the KA data that gets reset to default, it just the list of key attributes names. You will not lose data using the Quickstamp method that @mwra described.
@jmm Iād suggest reading up on prototypes and inheritance (here and here) as I think that will help understand whatās going on. Key Attributes (KA) are just those attributes displayed in the KA table in a given note. The list of attributes is stored in $KeyAttributesāas stated in @PaulWaltersālast reply. However KA have no effect on the attribute values themselves, but only on which attributes show in the KA table of a given note. The latter is down toā¦inheritance (qv).
The system attribute called KeyAttributes is a list . Hereās a list:
apples, pears, kumquats
hereās a list of attributes
Color, Shape, DEVONthinkGroup
the latter list can be the contents of KeyAttributes ā i.e.,
$KeyAttributes==("Color", "Shape", "DEVONthinkGroup")
Notice that (normally)** when the name of an attribute uses a dollar sign then we mean the value (or data) that an attribute takes in a note or system wide. When we donāt use a dollar sign, we mean the attribute without reference to its data.
So, again, when we change the KeyAttributes list, we just change the names of the attributes on that list ā we donāt change their data. And when we change $KeyAttributes in a note or a prototype, we change the list of attribute names for that noteās KA list. This can take a while to get your head around, but it is a common set of understandings needed when working with program code or data modeling.
** There are exceptions ā letās ignore that for now.