Bug Tinderbox: prototype cannot be changed when email is imported from Devonthink into Tinderbox

RRKLONT · August 29, 2017, 5:02pm

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.

mwra · August 29, 2017, 5:18pm

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.

PaulWalters · August 29, 2017, 5:24pm

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.

pat · August 29, 2017, 7:33pm

What does the arrow under “assigned to this note” do? I’ve never understood that one.

eastgate · August 29, 2017, 8:32pm

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.

mwra · August 29, 2017, 9:08pm

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.

jmm · November 17, 2017, 6:55am

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?

PaulWalters · November 17, 2017, 9:42am

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.

mwra · November 17, 2017, 11:14am

@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).

PaulWalters · November 17, 2017, 1:37pm

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.}