-
Notifications
You must be signed in to change notification settings - Fork 11
Assistant triggered by filters that execute moving / copying mail #143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Workarounds: at the moment I recommend not switching on the assistant automatically but only when it is needed. This will avoid most of the frustration of the assistant popping up unwanted. Make sure you download all mail beforehand and wait until it has processed all new email in the Inbox. Once it is done moving / tagging the incoming mail, it is safe to switch on the assistant to create some filters manually. |
Here is an idea for fixing this issue without returning to monkey patched code. The assistant could check whether there is a filter rule (like it does when it checks whether rules need to be merged) and whether that could have been fully triggered to cause the move. This means the filter action has to be move / copy to folder from the same source folder. |
Here is an implementation of the above idea, using the function To test this version, download the zip file and move it into Thunderbird Add-ons Manager (without extracting contents!) Added code (in // guard against being triggered during filtering:
// check if there is a filter for the folder
let filtersList = sourceFolder.getEditableFilterList(msgWindow); // msgWindow = global variable
let isFoundActiveFilterMatch = false;
for (let f = 0; f < filtersList.filterCount; f++) {
let aFilter = filtersList.getFilterAt(f), // nsIMsgFilter
acLength = qF.Util.getActionCount(aFilter);
if (!aFilter.enabled) continue;
for (let index = 0; index < acLength; index++) {
let ac = aFilter.getActionAt(index);
try {
if (ac.type == Ci.nsMsgFilterAction.MoveToFolder ||
ac.type ==Ci.nsMsgFilterAction.CopyToFolder) {
if (ac.targetFolderUri == targetFolder.URI) {
// now make sure that all filter conditions match!
// just use the first message
let ms = aSrcMsgs[0];
// match all search terms
let match = aFilter.MatchHdr(ms, ms.folder, ms.folder.msgDatabase, "");
// aFilter.MatchHdr(aDestMsgs[0], targetFolder, targetFolder.msgDatabase, "")
if (match) {
isFoundActiveFilterMatch = true;
break;
}
}
}
}
catch(ex) {
// NOP
}
}
if (isFoundActiveFilterMatch) {
if (isMoveListener) {
console.log(`No Assistant triggered by moving ${aSrcMsgs.length} messages, because a matching filter ${aFilter.filterName} exists and may have caused this event:\n`, aFilter);
}
return; // early exit
}
} |
Fixed in 5.7.1 - Published 26/Dec/2022 I think the logic to check whether an enabled filter could have caused the move is fundamentally sound - in this case showing the assistant dialog may have no additional benefit even if the move was cause manually / by user interaction. |
Hi |
I have noticed that the quickFilters assistant may be invoked (sometimes) when a filter moved or copies email. (See also #142
When filters are triggered automatically (or when I run them via the run filters on selected messages) this also invokes the assistant on my production profile. This is highly problematic, as the code currently cannot tell in the folder listener that checks for moved / copied messages what cause the event to be invoked.
If it doesn't work out I may have to roll back all the changes from the change set to "Remove monkey patch code for Tb move mail commands". Not sure how to distinguish between these cases (manual moving of mails vs filter caused moving) as of yet.
The text was updated successfully, but these errors were encountered: