AttachmentExtractor Continued - Version 4.0 für Thunderbird 91 - aufgegeben

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.

Zitat von J-K

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

Zitat von J-K

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.

Zitat von J-K

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.

Ich hoffe, dass mir keiner den Kopf runter reißt. Ich habe die Bugs als Duplicates markiert, sodass jetzt einer zentral übrig bleibt:

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.

Zitat von Thunder

Zitat von Thunder

Dazu muss ich wohl mal einen Bug aufmachen.

https://bugzilla.mozilla.org/show_bug.cgi?id=1721616

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.

Zitat von jobisoft

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.

Ich habe jetzt mal wieder 3 Tage lang damit verbracht, ein paar Schritte weiter am Code für ein neues AEC zu arbeiten bzw. teilweise schlichtweg Überlegungen dazu anzustellen.

Es gibt weiterhin zumindest 2 zentrale Probleme im Code von Thunderbird selbst, die gelöst bzw. verbessert werden müssen, da das Add-on sonst schlichtweg keinen Sinn mehr macht:

1. Das Versagen in IMAP-Ordnern, wodurch letztlich jede bearbeitete Mail hinterher als Duplikat vorhanden ist:

2. Das Zwanghafte anzeigen des "Speichern unter"-Dialogs bei Verwendung der korrekten Funktion zum Abtrennen der Anhänge. Es wäre notwendig dort einen vorgegebenen Speicherpfad an die Funktion zu übergeben, statt zwangsweise den "Speichern unter"-Dialog anzuzeigen. Es ist zwar möglich ein Array von Mails mit nur einmaliger Dialog-Anzeige zu verarbeiten, wenn man das Abtrennen manuell aufruft. Aber es macht für mein Add-on keinen Sinn, wenn ich nicht den Pfad vordefinieren und übergeben kann. Wer möchte schon bei der Automatik des Add-ons bei Eingang mehrerer E-Mails mit diesen "Speichern unter"-Dialogen "zugebombt" werden? 100 Mails mit Anhängen würden 100 mal den Dialog öffnen - das wäre Wahnsinn und würde jegliches produktives Arbeiten zunichte machen. Deshalb braucht man unbedingt die geforderte Erweiterung des Codes in Thunderbird, welche eigentlich mit relativ wenigen Code-Zeilen möglich sein müssten:

Es tut meinem Ehrgeiz eigentlich weh, aber ich sehe keine sinnvolle Möglichkeit an diesem Add-on weiter zu machen, wenn der Bug (in Nummer 1) und die Änderung (in Nummer 2) in Thunderbird nicht erfolgen. Ich werde sonst von Anwendern mit Fehlermeldungen für das Add-on (weiterhin und noch mehr) überflutet werden, die eigentlich auf Problemen in Thunderbird selbst basieren.

Bei alledem darf man sowieso nicht vergessen, dass das Add-on gleich mehrere experimentelle APIs benötigt, um wenigstens ein paar grundlegende Möglichkeiten aus den früheren Versionen anbieten zu können.

Alternativ könnte man natürlich gerne auch in Thunderbird selbst die Massenverarbeitung von Anhängen endlich mal einbauen. Es ist lange genug gewünscht worden:

Übrigens leidet auch das alternative Add-on an genau den beiden Problemen, welche mir die Sache versauern:

Punkt 1: Duplikate der Mails, wenn man ordnerübergreifend per virtuellem Ordner Anhänge löschen lässt. Eine Automatik gibt es dort nicht, würde aber identisch daran leiden.

Punkt 2: Der Detach-Prozess wird dort so improvisiert (genau wie in AEC bisher), dass anschließend kein Link aus den Mails zu den gespeicherten Anhängen mehr vorhanden ist (was eigentlich seit Thunderbird 68 der Fall ist). Dies ist letztlich auch eine der Folgen des von mir genannten RFE-Bugs.

Von meiner Seite ein Sorry für vermutlich leere Versprechungen bezüglich der Zukunft des Add-ons. Es wird von meiner Seite mit diesem Add-on hier erstmal nicht mehr weiter gehen.

Als Randbemerkung an jobisoft :

Die Filepicker API probiere ich tatsächlich zeitnah ein bisschen auszubauen und so zu gestalten, dass man diese allgemein nutzbar anbieten könnte. Vermutlich lege ich dazu ein eigenständiges Gitlab-Projekt an.