How do I set a custom attribute to default notes?
Instead of using tags and all the mental baggage that comes with that method, I prefer to jot a quick sentence about the context of the note.
“Personalization Summit keynote”
“Nadia asks about cohort report”
“Adjacent possibles”
This gives me a human-readable reminder of where the note came from and I can do a keyword search quickly.
I want this ‘Context’ attribute on every note I make. How can I do this with the document inspector?
Thank you Paul.
I have had success in the past with making a starter document.
I think I may have to rephrase my question. How do I get an attribute (preferably a user attribute) to be added to all future notes in a document when I hit ‘return/return’ to make a new note?
I don’t really want a prototype if I can help it. I want an unformed note with just a context field and no further assignments when adding a quick note.
It’s been a while, I feel like I’m simply forgetting something.
If I understand it you want an app-level default that allows you to add a user attribute as a key attribute to all new notes (in a new doc).
I don’t believe such is possible, so you’d probably make a feature request. I think @PaulWalters suggestions above get you about as close as possible to your desired behaviour.
@mwra, An app-level default would be ideal. I will make that request.
Is there a way that I can set all future notes in an existing document to have a user attribute?
Or, how can I set a system attribute to show on all future notes in an existing doc? A new doc?
What you want to do, I believe, is to set the default value of $KeyAttributes to include your new user attribute.
Once done, all new notes will have that user attribute. This is easy to do.
A more common approach might be to add that user attribute to a prototype, and then assign that prototype to newly-created notes. This can be automated by setting the $OnAdd method of your container to assign a prototype if no other prototype is assigned
$Prototype |= “NormalNote”
It worked! Thank you.
For posterity, adding values to $KeyAttributes will add KA to all future notes. It took a bit of poking around, so here’s a screenshot.
Left is the Inspector, right is a new note.
It also applies those to all existing notes where $KeyAttributes hasn’t been set directly or via prototype.
…plus the correct value for the default $KeyAttributes default value is not:
$Context;$Attendee;$Edition
It should be:
Context;Attendee;Edition
Why? In the first case, if the (doc) default value of any of those three attributes has a non-app-default value set then all notes get that value - not quite what you intended. In most cases the difference is moot…until you trip over it!
TL;DR - the default for $KeyAttributes is a List of the titles of the attribute names to be displayed, not the a list of the values if the default value of those attributes. If that makes no sense, the takeaway is:
Context;Attendee;Edition
…even if you’re not sure why!
Good to know, thank you!
Here are the two simplest ways I’m aware of to be sure that any attribute you have in mind is the default setting for new notes. It involves these steps, usually in combo.
*NewSamplePrototype, which has as its (only) Key Attribute $NewSampleAttribute. (For convenience, I name all my prototypes with * as the first character.) Thus any note based on this prototype will have this attribute. You’ll see that I have checked the box specifying this as a KeyAttribute for all such notes.
*NewSamplePrototype note.Obviously you can change prototypes after the fact - with agents and rules and stamps and other ways. But if you want to automate the process of setting up notes with certain attributes (and fonts and other traits), prototypes are for me the quickest and easiest way to go.
Regardless of prototype use, in documents for the long term I always place non-admin content inside one (usually) or more root-level containers. This keeps my data/writing clear of things like prototype, template, composite and other admin containers which all sit at root level. When querying the data, by looking only within/under the data container the admin content is immediately out of scope.
Probably because of advice by @mwra early on, I’ve long applied this practice, and endorse it (though it wouldn’t be evident from example-screenshots above). In most files I have just two root-level containers, “SYSTEM” and “DATA”. All housekeeping info – prototypes, agents, etc – is in SYSTEM. All actual info is in sub-containers of DATA.
Just endorsing the wisdom of this advice.
(Update: I realize that my original reply in this space mis-understood the argument of the one it was responding to, so I have deleted it.)
This is a very interesting idea. I’ve been doing the polar opposite for some projects. I will certainly look into this practice.
I’m a fan of a top-level note called CONTENT or NOTES. I have one tab that focuses just on that, so I can see my notes.
I’ve tried a top-level SYSTEM note as well, but if you create any built-in prototypes / templates then it creates their own top-level folder each time.
I do use a top-level separator to separate the system stuff from any other top-level containers that I create (dashboard, agents, etc).
Funny thing is, I pulled out a document from 2013 and I did put everything in containers. Prototypes are in a single container as well.
I quite like what I did with that 2013 doc, I may modify it for current use.
