Containers in my daily use of Tinderbox hold notes for a specific project or task. Since I have many small projects running in parallel I find it useful to not only retrieve notes that have been created say this week or this month using agents and the dashboard principle, but also which projects i.e. containers have contents that have changed.
I’m wondering what actions within a container holding notes leads to an update of the $Modified attribute ? For instance consider the following simplified case of a container with 4 notes. Adding a new note “Note 5” will not update $Modified date and time.
I suspect the only trigger to generate an update in $Modified is to make a change to the container note itself using a rule or edict that checks the container contents leading to a new, more recent $Modified value.
I’d keep track of changes to the container’s children in a separate date attribute — perhaps $MyDate, or perhaps a newly-defined date attribute. The OnAdd and OnRemove actions are then quite easy:
$MyDate(parent)=date("today");
Note that this in an OnAdd or OnRemove action refers to the note that’s being moved, so we have to explain that we want to change the parent, not its child.
Not entirely - for instance adding notes to a container note will modify it’s $ChildCount value but not $Modified (hence my initial confusion and question).
That is to be expected. $ChildCount is calculated, because it needs to reflect the number of children of the container. That’s not a direct property of the container, but about the container.
Originally, $Modified applied only to changes to a note’s (own (and not children’s/descendant’s) $Name and $Text. At some point I think it was extended to the notes current Displayed Attributes (excepting calculated attributes), the premise being that if you want to see certain attribute values all the time you likely want to know they have changed.
I’m not sure the range of attributes that affect $Modified are currently strictly documented. As best that I understand it is described here. If you know you want a scope different from that you’ll either need to set action code automation to capture it or make a feature request to have the app’s current behaviour modified.
But, ‘modified’ is certain only in the eye of the beholder, i.e. what user A thinks of as a recordable change will differ from user B whilst both will intuitively think their interpretation os correct.
So, to put this into an actionable context, what do you expect/intuit to cause $Modified to change? When we know that it will be easier to give a closer solution for your (and/or confirm what can’t be recorded in such a way.
Thanks @mwra.
It would be worth clarifying precisely what changes the $Modified as one of the few track-changes attributes for the following reasons:
I expect that sorting, retrieving and analysing notes based on the $Modified attribute is common e.g. to answer questions on which notes have changed recently etc…I use it a lot in cases such as above.
The interpretation of $Modified may change considering individual notes (when was this note) to containers which is more ambiguous (when was the container modified as a note vs when was the content of the container modified).
The current aTBref documentation in your link states that changes in $Text, Displayed Attributes or Get Info Attributes trigger an update of $Modified. There is no distinction between calculated or other attributes and the Get Info attributes to by knowledge includes $ChildCount too.
From my perspective it would be better to trigger an update to a container note when a specific list of note attributes are updated, including container “aware” attributes such as $ChildCount. Like that the user has a clear understanding of the triggers and can use this knowledge in note analyses.
At present, $Modified is updated when the text changes, or when you edit an attribute in the Displayed Attributes table. It isn’t changed when an action changes an attribute.
One thing we want to avoid is a situation in which $Modified becomes meaningless because almost everything is modified almost all the time. For example, if you change a default value of an attribute — say setting the default of $Width to 5 — should every note that uses the default be marked as modified? What if an agent sets the $Color of a note to “red”: does this modify notes that were already red?
Thanks, I think I’d missed that in my docs and add it to the description as it’s an important distinction (user vs automation).
The examples above help lay bare what an (unintenionally) loose definition ‘modified’ can be. I’ll try and capture some documentation on this aspect too. There’s no error in the opening question, other than it proves to be an expectedly ill-defined notion.
