'Find' function crashes shortcuts app

What I did: Planned to use the Agenda ‘find’ in the shortcuts app to filter notes by creation date but…

What happened: the shortcuts app crashes as soon as you select ‘add filter’.

What I expected: not to be dead in the water

Things that might be helpful to know (Agenda version, OS and model, etc):
Version 18.3.2 (295) - Mac App Store.
OS 14.4.1 (23E224)

My workflow depends on filtering on created as well as retrieving the created date of specific notes to find days alive and days since last edit. It’s a date focused app!

My workflow depends on filtering on created as well as retrieving the created date of specific notes to find days alive and days since last edit. It’s a date focused app!

…this was my first thought:
Why do we have to tinker with things like this at all? Why can’t Agenda do this directly yet? :face_with_monocle:

We are working on new search functionality right now, and it will add options like this. Will be in Agenda 19, which is not far away.

For now, which app crashes? Shortcuts or Agenda? If it is shortcuts, not sure we can do much.

It’s the shortcuts app which crashes, only on MAC, on iPad it doesn’t.

I had intended to post related feature requests in a separate post but frustration got the better of me because it’s part of a larger issue of not being able to retrieve certain data for use, not simply displayed for viewing or searching. In this case, created and modified (actual variables would of course remain read only). A few new note info variables: Days since created and Days since last edit. Unless these are already available they can’t be searched for, listed, or acted on. Also it would be very helpful if a selected note could perhaps from the cog icon, display notes it was linked to in a new window. From that window, those notes could be similarly acted on by deleting or adding link(s). Thanks.

I think exposing the creation and modified date in shortcuts is something we should do. I think the “days since” could then be scripted, since it is a derived quantity.

The cog menu idea is interesting. We’ll take it along. Thanks!

Thanks for considering exposing the 2 date items to work with and giving some thought to a way to make links and backlinks a step closer to first class citizens of Agenda.

As for leaving derived data regarding dates to shortcuts, I find that very disappointing. The actions based on those parameters done via shortcuts, absolutely. Who knows what others might use them for, perhaps setting alerts based on how long it’s been since edited, or decide the note or planned project is now irrelevant.

My point is that they are derived quantities. If you have the creation date, I assume you can do any number of things with it, and calculating the days since should be reasonably straightforward I assume.

What is your concern exactly? Exposing properties for every conceivable use case is not a good API. A good API is exposing the necessary fundamental properties, so that people can use those properties in any way they desire.

Please let me know why you find it a problem.

Getting created days to date only is straight forward with creation date being a fixed parameter. It could be determined at any time, combined with alerts getting days remaining to some milestone or end date alert for the note or project but you could be late in discovering it. It could make an easy low value shortcuts candidate.
Modification date, a moving target, is a bit different. It’s updated automatically by any input, so time since the last modification is straight forward as well and you could easily run a shortcut but the result could be sketchy. Intended or not, any input will determine the next value. The result will not be accurate due to the the length of time of the last edit; the modified parameter is the start of edit. Also, there aren’t many options in what you can do with the result. You could of course set an alert as with created but since the purpose would be to find the late, neglected, or forgotten you would need to do it via search of all undone notes.


If desired we could raise our dates based note system a notch as I am now with specific projects.
In a nutshell I enter “\n”(date/time now) at the start and end of a new edit. These go to a spread sheet that is sectioned off by Project section. From this I get the time between edits and the the actual edit time as mmm as well as a rolling total of both for each note, project section and project total. At the end of project, or any time really, I have billable and nonbillable hours for each section of the project and then determine averages to better estimate future project and section times. Even with automation the start and end times would currently have to be triggered by hand as the user is the only one who knows when that happens. I’m trying to figure out how to prevent an automatic new start time that is not preceded by an end time because even when working outside of Agenda that time can still be attributable to that particular notes edit time.
I did mention I was doing all of this by hand for the last many months? It’s a PITA but wala, Agenda now has a time tracker when needed.:smile:

Whoa, that sounds like next level automation. An app built-on an app :slight_smile:

(Actually, I was around when OmniFocus was first developed. It was based on some AppleScripts that you could run with another app, OmniOutliner I think. Script was made by a user of the app. Omni hired him, and developed OmniFocus around the idea.)

1 Like