Von daher sind beide Ansätze legitim, oder?
Ja, es wäre besser, wenn es auch mit der Systematik mit mehreren aufeinander folgenden Filtern mit jeweils getrennten Aktionen funktionieren würde.
Aber das viel größere Problem für mein Add-on ist das teilweise Versagen der Detach-Funktion bei IMAP-Ordnern.
Dazu muss ich wohl mal einen Bug aufmachen.
Ich habe diesen Bug wieder geschlossen, da ich selbst einen Fehler in meiner Filter-Systematik drin hatte. Theoretisch könnten aber auch andere Anwender den gleichen Fehler begehen. Trotzdem funktioniert das Taggen zuverlässig, wenn man die richtige Systematik verwendet. Dieses Problem hat sich also für mich erledigt.
Das Problem mit den doppelten Mails und dem dann konsekutiven erneuten event onNewMailReceived tritt tatsächlich bei mir nur in IMAP-Konten bzw. Ordnern auf. In POP-Konten passiert dies nicht.
Ich hoffe, dass mir keiner den Kopf runter reißt. Ich habe die Bugs als Duplicates markiert, sodass jetzt einer zentral übrig bleibt:
Deswegen der Workaround die Nachricht mittels Message-ID im Original-Ordner öffnen und dann dort den Anhang abtrennen. Danach muss wieder in den Virtuellen Ordner gewechselt werden, um die nächste eMail mit großen Anhang zu finden…
Ahh okay. Jetzt verstehe ich Dein Vorgehen. Eigentlich "irre" das (Workaround-)Prozedere, aber der virtuelle Ordner ist dann irgendwann leer, wenn Du alle abgearbeitet hast.
Wenn ich den Anhang in dem Virtuellen Ordner abtrenne, bleibt die Original-Nachricht erhalten.
Ahh ja, dieses Szenario hatte ich ganz vergessen, obwohl genau dies für die neue Version des Add-ons als Methode zum Löschen über Ordnergrenzen hinweg den Benutzern vorschlagen wollte.
Mein Workaround bisher: Auf die Nachrichten-ID klicken, die ich über
mailnews.headers.showMessageId = true anzeigen lasse, dann gelangt man in den passenden Ordner.
Ich verstehe den Sinn der Aktion gerade nicht 
Knackpunkt ist, dass man es manuell ja nur machen kann, wenn man den Fokus auf dem Ordner hat.
AEC ruft die Routine aber für die Automatik auch auf, wenn man in einem anderen Ordner ist.
Die originale Mail wird nicht gelöscht:
* Ist das neu? Siehst du einen Zusammenhang mit meinen letzten API Änderungen?
Nein. Das Phänomen gibt es schon lange. Ich bin dem nur nie systematisch nachgegangen.
Der event wird (wohl als Folgeerscheinung) zu Unrecht erneut gefeuert:
* Ist das neu? Hat meine "alte" Version des onNewMailReceived events mit der manuellen "kenn ich schon" Unterdrückung da nicht gefeuert?
* Feuert TB selber?
Es ist vermutlich nicht neu. Und JA, Thunderbird feuert auch selbst - es gibt ja auch eine zweite Mail, da die Originale nicht gelöscht wird.
Das detach ist legacy code von dir?
Ja, aber es handelt sich dabei ja um eine Thunderbird eigene Funktion:
messenger.detachAllAttachments(
types[i],
attachmentUrls[i],
originalFilenames[i],
messageUrls[i],
false,
true
);Das folgende Addon ist ausdrücklich NUR für Versuche geeignet! Normale Anwender sollen dieses Add-on nicht installieren und verwenden!
Thunderbird Daily vom 23.7. hat jetzt Deinen letzten Patch für den event mit drin. Damit habe ich die letzte halbe Stunde Tests durchgeführt. Das folder Object wird wieder korrekt zurückgegeben.
Ich schreibe dies hier auf Deutsch, da ich mich einfach besser ausdrücken kann...
STR:
Und genau in Punkt 6 liegt nun gleich der doppelte Fehler:
Wenn man obige Schritte macht, während der Fokus im Posteingang (bzw. im Ordner mit der originalen empfangenen Mail mit Anhang ist), dann werden die Schritte von Thunderbird korrekt erledigt.
Im Beitrag wird nur ein Ausschnitt des Screenshots angezeigt
Du hast den Screenshot zwar als Dateianhang korrekt hochgeladen, aber nicht in den Beitrag eingefügt. Übrigens kannst Du beim Erstellen eines Beitrags im Forum per Drag+Drop von Deinem PC einen Screeshot direkt in den Beitrag einfach hinein ziehen.
vollständig anzeigen
Wir können den Screenshot trotzdem vollständig anschauen. Man muss diesen einfach nur anklicken bzw. "öffnen". Die anonymisierte E-Mail-Adresse stellt sich für den Leser einfach als Hieroglyphen dar 
beispielhaft "bernhard.96@gmx.de"
Solche Adressen hat hier wohl so ziemlich jeder Benutzer in Thunderbird in Verwendung. Diese funktionieren ohne Probleme. Daher muss das Problem bei Dir anders verursacht sein.
In Deinem (zurecht) anonymisierten Screenshot brauch man ziemlich viel Phantasie 
. Ich kann das beschriebene Verhalten von meiner Seite nicht bestätigen.
Ich könnte mir vorstellen, dass man die "Tags" dafür in Zukunft nutzen könnte. Wer möchte könnte per Filter beliebige Tags (pro Konto oder auch für andere Kriterien) vergeben lassen. Das Add-on könnte dann im Standard-Speicherpfad des Automatik-Modus jeweils automatisch Unterordner mit den Namen der Tags erstellen.
Mit getrennten Profilen je Konto kannst Du natürlich jeweils ein anderes Ziel für den Automatik-Modus festlegen.
Das geht so nicht automatisiert. Dafür müsste man das Add-on beispielsweise in Thunderbirds Filter-Aktionen integrieren, was mein Können übersteigt. Das bisherige Add-on wird eh für Thunderbird 91 von einer komplett neu programmierten Version 4 ersetzt werden, die zwangsweise (zumindest erstmal) abgespeckt sein wird. Ich muss dann sehen, was ich im Laufe der Zeit wieder mit den neuen Techniken einbauen kann.
2FA ist inzwischen optional verfügbar. Man kann es also im Benutzerkonto des Forensystems freiwillig aktivieren.
danke fürs finden, ich geh das mal fixen.
Super, wenn Du's so schnell nachvollziehen kannst - Danke!
Hast du meine Kommentare im Bug gesehen? Inzwischen wurde der bug als gefixed geschlossen.
https://bugzilla.mozilla.org/show_bug.cgi?id=1716051#c10
Sollte im aktuellen Daily drin sein, inzwischen.
Leider hat entweder dieser Patch oder etwas anderes eine Regression erzeugt: Der event onNewMailReceived müsste ja die beiden Objekte folder, messages zurück geben. folder ist jetzt aber immer null. Dieses Problem habe ich in Deinem speziellen Build genauso wie in den aktuellen Daily-Builds. In 91 Beta 2 ist dies aber noch in Ordnung.
