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

  • Hallo Ihr zwei,

    wenn ich im Thunderbird einen Anhang abtrenne, habe ich danach auch zwei Mails.

    Einen mit und einen ohne Anhang, das habe ich aber schon sehr lange und die Erweiterung zu abtrennen habe ich nicht installiert.


    Gruß

    EDV-Oldie

  • Bei manuellem Abtrennen eines Anhangs, wenn der Fokus nicht im Orginal-Ordner ist, habe ich ebenfalls ohne Erweiterung das Problem, dass die Originalnachricht nicht gelöscht wird:

    Ich habe einen Virtuellen Ordner mit der Suchbedingung: Größe (kB) größer als 1000kB angelegt. Wenn ich den Anhang in dem Virtuellen Ordner abtrenne, bleibt die Original-Nachricht erhalten.



    Mein Workaround bisher: Auf die Nachrichten-ID klicken, die ich über

    mailnews.headers.showMessageId = true anzeigen lasse, dann gelangt man in den passenden Ordner.


    Das funktioniert allerdings leider nicht immer, die Fehlerkonsole zeigt dann:

    Quote
    Uncaught TypeError: true is not iterable
    SearchForMessageIdInSubFolder chrome://messenger/content/mailContextMenus.js:307
    OpenMessageForMessageId chrome://messenger/content/mailContextMenus.js:209
    MessageIdClick chrome://messenger/content/msgHdrView.js:2389
    MozMailMessageid chrome://messenger/content/mailWidgets.js:223
    mailContextMenus.js:307:50


    Ich würde mich sehr freuen, wenn das automatische Abtrennen der Dateianhänge mit der Erweiterung funktioniert! :)

  • 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 :/

  • 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.

  • Hallo Thunder,

    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 :/

    Weil ja sonst die Original-Nachricht erhalten bleibt, wenn innerhalb des Virtuellen Ordners abgetrennt wird. 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…

  • 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.

  • Eigentlich "irre" das (Workaround-)Prozedere, aber der virtuelle Ordner ist dann irgendwann leer, wenn Du alle abgearbeitet hast.

    Ja, ich habe mir bloß noch nicht die Mühe gemacht, zu schauen ob es einen Bug-Report gibt oder andernfalls einen zu erstellen…

  • 681951 - detaching attachment duplicates mail in unified folder view
    UNCONFIRMED (nobody) in Thunderbird - Folder and Message Lists. Last updated 2015-09-27.
    bugzilla.mozilla.org


    518891 - detach/delete attachment does neither: results in duplicate email w/attachment
    NEW (nobody) in Thunderbird - Folder and Message Lists. Last updated 2019-01-15.
    bugzilla.mozilla.org


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


  • 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.

  • Gut zu wissen. Die UI macht aber nicht deutlich, dass es besser ist einen Filter mit mehreren Aktionen als mehrere Filter mit Einzelaktionen zu definieren, oder? Von daher sind beide Ansätze legitim, oder?

  • 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:


    1578801 - Provide an additional save path attribute in function call nsMessenger::DetachAllAttachments().
    NEW (nobody) in MailNews Core - Attachments. Last updated 2021-06-11.
    bugzilla.mozilla.org


    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:


    92146 - [RFE] Save/Open/detach/delete all attachments in multiple/many selected messages
    RESOLVED (nobody) in MailNews Core - Attachments. Last updated 2021-07-23.
    bugzilla.mozilla.org


    Ü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.

  • Thunder

    Changed the title of the thread from “AttachmentExtractor Continued - Version 4.0 für Thunderbird 91” to “AttachmentExtractor Continued - Version 4.0 für Thunderbird 91 - aufgegeben”.
  • Ich habe heute die Roadmap für TB103 besprochen, und da ist auch eine WebExt API vorgesehen, die messages in place verändern kann. D.h. den raw content, header und damit auch attachments.


    Ich werde mich etwas intensiver mit den beiden bugs beschäftigen. Bug 1089452 scheint ja ein generelles Ärgernis zu sein.


    Bei Bug 1578801 ist es etwas komplizierter. WebExtension haben ja keinen direkten FS Zugriff. Sie können einen html <input type="file"> benutzen, um ein File oder FileList Object zu erhalten. Das können Sie aber glaube ich nicht abspeichern (da es kein serialisierbarer Filetype ist, kein JSON). D.h. einmal pro Session musst du den Pfad abfragen.


    Als Experiment kannst du das natürlich umgehen, wenn du an die Core Funktion den Pfad übergeben kannst. *grübel*


    Bug 292067 würde das in der Tat lösen. Dann würde ich das aber auch in das Context Menu packen, wenn mehrere Nachrichten selektiert sind. Nicht einfach das Thema.

  • 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.