sballin

should be fixed as of 3.6.2

Interesting, I never noticed that. Does it cause any problems when working with notes created through the workflow? I guess this could be fixed by changing the applescript to just do command-n, type title, press enter twice. I'll add it to the to-do list.

can you post a screenshot?

I decided this should be the default action of alt-enter in the latest version: https://github.com/sballin/alfred-search-notes-app/releases/download/3.6/Search.Notes.alfredworkflow This new version also has the following features: Show enclosing folder when showing a note Use new note linking format that works on macOS and iOS (macOS >= 14 required) Use new updater script that doesn't require Python 2 (thanks vitorgalvao!) Bug fixes

Glad you like it! What version of the workflow are you using? Can you post the exact result? The newer iOS/macOS Notes apps now have built-in note linking support, so I’m not sure about the future of this feature…

I can see why it would be flagged, because it accesses the Notes database. But not sure anything can be done here other than to “unblock” it or turn off app block. You are welcome to inspect the source and compile it yourself following the directions in the readme.

I think the first one is satisfied by the keyword "nt", the second one I can add to the to-do list

Should fix it if you double click on the block that's called "Create new note" in the workflow diagram and replace the code with this: on alfred_script(q) try tell application "Notes" -- Create new note from user query tell default account to make new note at default folder with properties {body:"<div><h1>" & q & "</h1></div><div><br></div>"} show first note in default account show first note in default account end tell on error errorMessage number errorNumber display alert "Create Note Error" message (errorNumber as string & ": " & errorMessage & "\n\nInput: " & q) as critical end try end alfred_script

did you try searching for a note after opening the debug log?

what does the debug log say?

what’s the error message?

Did you try disabling and re-enabling those permissions?

That's right, they only appear when searching the note body text. The OCR is done by the Notes app itself automatically whenever I drag and drop an image into a note or add handwriting to a note (I'm on Big Sur). The OCR is pretty good but not 100% accurate, which might explain any inconsistencies with the search. The feature doesn't include PDFs or other non-image attachments—I don't know how to search those unfortunately.

Sounds like Alfred may not have full disk access, something similar happened to another user after upgrading to 11.4: https://github.com/sballin/alfred-search-notes-app/issues/43#issuecomment-867308050 Here are what the permissions should look like: https://github.com/sballin/alfred-search-notes-app#required-permissions

Do you have "n" set as the keyword for "Opening Files" in Alfred Preferences > Features > File Search?

Weird... here are a couple more things you can try: 1. Locate the binary in (workflow directory)/search_notes, it's the file named search_notes. Right click the binary and press Open (don't do anything else like double click, cmd-down, etc). This is supposed to be equivalent to "Allow Anyway" 2. Try running the binary in the terminal (cd to search_notes directory and do ./search_notes) 3. If neither of the above work, try restarting your computer, or doing 1/2 on a different computer...

In the security pref pane, do you have "Allow apps downloaded from" set to "App Store and identified developers?" Does anything show up in the error log or alfred debug log when you try to open it?

Version 3.3.0 is released! New features: Choose between creating a new note or searching note bodies when no note with a matching title is found (set your preference in environment variables) Better support for accented characters Paste note links quickly using a snippet shortcut

Here is a pre-release version where characters like that should be handled properly: https://github.com/sballin/alfred-search-notes-app/files/6168245/Search.Notes.zip Let me know if you encounter any issues!

Weird! I'll have to think about this. I was able to reproduce your error message with a note containing "İ" but removing the error handling didn't fix things for me.

Thanks for reporting this issue. I don't think it's security related, that error message is always the same because it's the most common problem users face. I think it's because of certain characters like i/İ having different byte length depending whether they are uppercase or lowercase, and the workflow converts notes to lowercase when searching. I'll work on a fix...

You could create a new "Run NSAppleScript" action with the following code: on alfred_script(q) tell application "Notes" -- Show user requested note -- Get note id which is first item in q set noteID to text 1 thru ((offset of "?" in q)-1) of q show note id noteID in default account show note id noteID in default account -- Click menu Window -> Float Selected Note tell application "System Events" to tell process "Notes" to click menu item 11 of menu 7 of menu bar 1 end tell end alfred_script

I was talking about the notes:// links you get from doing the alt-enter action on results. If you don't use that feature, everything else should be working as usual.

Looks like in Big Sur the notes:// URI scheme is handled by the Notes app directly, meaning that notes://seemingly-any-string-here causes the Notes app to come into focus, but do nothing further. It's possible to get around this with SwiftDefaultApps and make notes:// links work as before, or it would also be possible to change the URI for links generated by this workflow (note:// seems like a good alternative). But does anyone know how the default macOS notes:// URI scheme handling works? Is there some documentation anywhere?

Thanks for letting me know, I wasn't aware of this issue. Looks like notes that are not from iCloud or On My Mac are not stored in the normal database. If anyone figures out the details, I'm happy to try adding support.