$Modified Behavior Question

Agents, Actions and Automation Posters
1

Perhaps a bug, perhaps I’m misunderstanding something.

In Captain’s Log, I have a boolean $Reviewed that is checked when I’ve reviewed the entry (and presumably taken any action necessary).

I perform this action in an Agent that collects unreviewed entries, so these are aliases I’m working on. (Pro tip: Don’t check “Reviewed” until you’ve finished taking any other actions necessary.)

As a result of the the above (the note disappears from the Agent, because I checked “Reviewed,” and then tried to change an attribute), I created an Agent to collect Recently Changed, so I can look at all the entries I’ve just reviewed. I was trying to set the “recent” interval to the past two hours, so the query is this:

$Modified>=date("today-2 hours")

So far, so good. It seems to collect the relevant entries, “seems” being the operative word.

In aTbRef, $Modified should include any attribute.

W/hat I am observing is that the only entries that the query is gathering are the entries where I edited the $Text of the entry. Simply checking $Reviewed will not trigger the query.

I verified this by watching the two agents in the same view as I reviewed unreviewed entries, and did not see them appear in the Recently Changed container if I just checked $Reviewed. If I edited the $Text, they would appear in the Recently Changed container.

Now, trying to be a good Tinderbox citizen, I created a new entry in today’s log. It appeared in both containers with a $Modified time of 09:52. While writing this, I paused and went to the log and checked $Reviewed (at 09:57).

The entry dutifully disappeared from the Unreviewed container (Agent), and remained in the Recently Changed container (Agent) (because it’s within the last two hours), but $Modified still showed 09:52.

So, is it a bug, or I have I misunderstood $Modified?

I :heart: Tinderbox

2

Whilst I’m not sure how it plays out in the overall, this partial quote changes its meaning:

The actual source ‘any attribute’ text in context is:

The meaning of any attribute is not the same in both contexts and this might leads to some confusion for the reader. But, I’m assuming, from the run of text in the opening post that $Reviewed is in the Displayed Attributes table. So thus we’d expect an edit of $Reviewed to work.

Originally, $Modified simply tested if $Text had changed. In v8.8.0 (see) it changed to the above. This is, on checking deeper actually explained better (note to self) in the Release notes for b477 in Notes.tbx:

Changing an attribute value in the displayed attributes table or in Get Info: attributes now updates $Modified. Changing an attribute value in a stamp (including Quickstamp) or an action does not update $Modified.

IOW, if the Get Info (pop-ver or turn off dialog) is open and an attribute is modified, an edit of a value is assumed to set $Modified, i.e. update it to the system date/time as as that edit.

Testing:

Untitled 2025-03-11 15-19-31
Untitled 2025-03-11 15-19-311326×440 57.1 KB

The above note was made today as 15:16. At 15:18, I ticked the $Received and $Modified was not updated. But if I edit in $Text. So $modified is getting changed

Thus, as per documented behaviour, for $Modified, this appears to be a bug. Butit might equally be a case of the change trigger(s) being incorrectly described (via my reading of RNs). Either way, simplistically from a user standpoint the feature doesn’t work as documented.

Testing further with a mix of system and user attributes as Displayed Attributes, edit in the Displayed Attributes did not appear to affect $Modified. Simlarly, Get Info edits had no effect. $Text edits did alter $Modified.

@eastgate am I correct in thinking $Modified update triggers have reverted to the older (pre-v8.8.0) behaviour of only reflecting $Text changes?

1 Like
3

I suspect that something is amiss, specifically, with booleans displayed attributes.

2 Likes
4

I’m confident a fix will be forthcoming. It’s not a show-stopper, by any means. :grinning:

1 Like