Feature request: include foldername as a parameter in "Run application"

[kupietools]

I'd like to use "Run application" with TerminalNotifier on mac to display custom notifications. It'd be nice if there was a @MAILFOLDER@ parameter giving the name of the folder the email was in. Like, the originating folder if "run application" was called before any filter steps that moved it, or the folder it had been moved to if afterwards. Thanks.

EDIT: You know what? I just realized this is very easy to parse out of the message URI. with thefolder=$(basename "$themsg_uri" | sed -e "s/[#0-9]*$//g"). I'll leave this up here for your consideration, but it turns out I myself don't actually need it.

[RealRaven2000]

Looks interesting. so you need a new parameter that converts the folder's URI into a real file location? It may just be slightly tricky across various OS but not impossible.

[RealRaven2000]

Only question: do you mean the current mailfolder location of the email, or the one that it will have after moving to another folder? That may be slightly harder because it is difficult for one filter action to know of the existence of other actions. and moving mails is asynchronous.

[kupietools]

Looks like we might have crossed in the wires, don't know if you saw my edit, but I figured out how to parse this out of the message URI on my receiving script, so no urgency on this from me. I've actually got a bash script now which will fully bridge filtaquilla to Terminal-Notifier.app, with this last bit of the puzzle in place FiltaQuilla can now replace the obsolete Mailbox Alerts plugin for me. (I'll post the script to github when I get the chance.)

Anyway, my thought was, wherever the message is at the time the script step executes, that's the folder the token would return. For my purposes, I have it at the bottom of my filter list, after all filters or actions that would move the email, so it shows the destination folder, although FQ doesn't have to know that, the move was done by previous filters. The current message URI at whatever time the step is called pretty much always gives the folder I want.

By asynchronous I don't know if you mean there's a chance an earlier filter's attempt to move the email to a different folder might not have actually been executed yet by the time a later filter calls Run Application, but if so, in practice, I haven't run into that problem in my testing. Yet.

If someone wanted to be alerted before things get filtered into other mailboxes, they could put the filter with the Run Application first in their list.

[kupietools]

Oh, you know what? I just reread your comments. No, I wasn't even looking for the folder's location... I just wanted the name of the folder, for purposes of displaying it in a notification. That was the original request, but, as I said, I realized I could parse it out of the message URI myself.

[RealRaven2000]

ok. so the current folder is not a big deal. the future folder name (assuming the next or previous step in the actions list is "move to folder XYZ") may be a bigger problem.

An asynchronous function work like this: you tell the function to start and then the normal flow of execution resumes. You trust the function to execute sometime in the future and be finished then. If you need to execute something after the function is finished then there are technical methods of waiting for it. either by adding a callback function (which will be called once the mail has been fully moved or the function has failed), or by using the keyword "await".

But here is the problem you cannot await an asynchronous function unless you call the code from another asynchronous function. But the filter actions are currently designed as synchronously, so we cannot do that. We can call an asynchronous function but we cannot know when it is finished.

A lot of the new API functions that the new (permission based) web extensions can call are actually asynchronous, but the filter code is quite old and still synchronous. This presents a number of challenges for writing modern, multifunctional code, and it is often hard to explain to the layman.

[kupietools]

Ugh. Sorry, I wasn't clear... I've been a developer for a very long time, written tons of jQuery, etc, so I understand a lot about it & know the difference between synchronous & async functions, js promise & await, etc, But I just don't get how things are implemented in Thunderbird in particular. Javascript is fundamentally a reactive language, I have never thought it was very suited for writing a desktop app in.

As I said, I don't really need this as I've found my solution by parsing the message URI, but, if you do think this is worth implementing in FQ, I don't think it needs to be as complicated as you're worried it might be. At any given moment, the message does have a URI, and that URI does contain a folder name... I think a token to send that folder name should be sufficient. It is whatever it is.

If there's a real problem with the asynchronous message movement, it seems to me in my testing that in practice, having the Run Application step in its own filter, at the bottom of the filter list, gives TB enough time that everything has moved to where it needs to be and the @MESSAGEURI@ is sending my bash script the correct folder that the email has been moved to. Might not work that way if you have actions to move the mail right there in the same filter, but, anybody using this should be knowledgeable enough to understand a warning that that might not work as expected.

BTW not trying to self-promote, but in case anyone reading this is interested, I've posted the bash script I use to get FiltaQuilla to talk to Terminal-Notifier.app on Mac, including how I set up the action in FiltaQuilla, at https://github.com/kupietools/terminal-notifier-bridge-for-thunderbird/ .

[RealRaven2000]

If there's a real problem with the asynchronous message movement, it seems to me in my testing that in practice, having the Run Application step in its own filter, at the bottom of the filter list, gives TB enough time that everything has moved to where it needs to be and the @MESSAGEURI@ is sending my bash script the correct folder that the email has been moved to. Might not work that way if you have actions to move the mail right there in the same filter, but, anybody using this should be knowledgeable enough to understand a warning that that might not work as expected.

yeah, whatever it is it won't work in the same filter. the filter execution is dumb and probably executes the action steps one after the other (assuming that they are synchronous). So even using tags and splitting into 2 filter actions won't help. the only thing that would help is if we could create filters to automatically run on other folders than the inbox; they would have to be tested by Thunderbird Core to make sure the emails have "fully arrived" in the new folder.

thanks for sharing the script! I haven't tested any of my hypotheses but I can get the message from the database and from that the current message.folder.prettyName.

[RealRaven2000]

try this one, the parameter name is @FOLDERNAME@ - since the @MESSAGEURI@ parameter also already uses folder, I don't see a big problem adding the name:

filtaquilla-4.0pre19.zip

---

To test the version above, download the zip file, drag the file into Thunderbird Add-ons Manager, do not extract contents or if won't install.

[kupietools]

Yep, works for me! The new token sends the folder name to my script. Thanks!