Ich synce diese Felder, damit genau das geht was du gerade erlebt hast 
CardDAV ist ja unglaublich flexibel und unterstützt custom fields. Ich benutze z.B. X-MOZILLA-CUSTOM1 etc. für diese Felder. Deine MacAdressbuch kennt diese Felder nicht und zeigt sie nicht an, darf sie aber auch nicht anfassen/verwerfen. TB68/TbSync kennt es aber und kann es auch wieder anzeigen.
Ganz unten in dem von dir gezeigten Dialog sollte stehen, das einige Eigenschaften nicht geändert werden können, wenn das Account aktiviert ist. Ist der Hinweis da?
Also du musst das Account deaktivieren, dann die Option ändern und dann wieder deaktivieren.
Klappts?
Hallo EDV-Oldi,
das von dir geschilderte Problem kann ich leider mit meinen Servern nicht reproduzieren. Nur um sicher zu gehen: Du nutzt für TB60 und TB68 nicht das gleiche Profil, oder?
Um das wirklich reproduzieren zu können, bräuchte ich ein Testaccount auf deinem NAS.
D.h. wir verschieben das von AEMessage nach AETask? Bist du sicher?
Ok, dann reverte zunächst deinen (meinen) letztem Commit, dann ist das async erstmal wieder raus.
Dann musst du die Funktion getAttSize aus AEMessage rausholen. Du könntest Sie in EATask stecken, oder einfach als normale Funktion ganz nach unten unterhalb von AEMsgWindowCommands definieren:
async function getAttSize(...) {
...
}Die ist ja unabhängig von irgendwelchen Objekten.
Nach dem Revert, müsste in saveAtt() wieder der simple Aufruf von getAttSize().then( .. irgendwas mit console.log .. ) drin sein. Den ganzen Block, verschiebst du dann dahin wo du ihn haben willst/brauchst. Hast du in AETask Zugriff auf die prefs?
Ziel ist, dass du wieder die Größe der Attachments und auch alle relevanten prefs/variablen im log siehst, die wir zur Entscheidung von sizeToSmall brauchen.
Wenn das wieder klappt, guck ich mir an, welche Funktionen dann alle async werden müssen.
Meld dich, wenn was unklar ist.
Also ich komme mit gitlab nicht klar. Ich habe meinen Fork gelöscht, neu geforked, die Änderungen neu gemacht und kann jetzt trotzdem nur auf deinen master mergen. Hier ist jetzt einfach die "neue" Datei am Stück, kannst du die bei dir einfach selbst committen?
Wenn ich merge requests erstellen will, kann ich nur lokale MR erstellen, dein Repo kann ich garnicht auswählen. Manchmal taucht eine vorgegebene Option "merge in ThunderbirdMailDE/attachmentextractor master", wo ich aber nix änder kann. Sehr sehr komisch. Musst du mir irgendwie eine merge berechtigung geben?
Zu deiner Frage: Es geht nicht um Performance. Es geht darum, dass fetch() async ist und wir das jetzt benutzen müssen, um an die size zu kommen. Async ist die Zukunft, weil das multiple threads nutzen kann. Async ist also auf jeden Fall gut (deswegen ist fetch() asyny). Man muss keine Callbacks mehr definieren (so wie jetzt bei setTimeout, z.B.), die geschachtelt echt widerlich werden. Mit async/await kann man async code schreiben wie früher sequentiellen code.
Das Problem, man kann sync code nicht einfach so in async code umwandeln. Die Funktion saveAtt() muss auf jeden Fall async werden, damit wir darin await getSize() machen können. Jetzt muss man in der call sequence nach oben gehen und eigentlich jeden Aufruf in der Hierarchie überprüfen und gucken, wo man den Übergang von sync zu async machen kann. setTimerouts sind super, die erzeugen ja quasi bereits parallelen async code und daher kann man da ganz prima den Übergang machen.
Problematisch ist der Aufruf von saveAtt(0) (ich hab gerade ein Kleinkind aufm Schoß, daher keine Zeilennummern). Wenn ich das so lasse wie jetzt bei mir committet, ändert sich der Execution flow: Anstatt saveAtt(0) auszuführen, wird es als Hintergrund-Task geplant und dann direkt weiter gemacht, ohne auf das Ausführen von saveAtt(0) zu warten. Das muss ich mir noch genauer Angucken. Kannst du einfach mal ausprobieren, ob es funzt?
GitLab has some strange limitations. I cannot create a merge request for your dev-next-68 branch. Only into your master. Even though I commited my changes into the dev-next-68 branch of my fork.
Could you make your dev-next-68 branch the default branch (if that is possible with GitLab)?
Email erhalten, danke!
Dürfte ich dich bitten, mit allen TbSync Modulen in deinem TB68 auf den beta release channel zu wechseln, und es nochmal zu probieren, nur um auszuschließen, dass ich es nicht schon gefixt habe? Über den beta release channel, kann ich - falls nötig - auch viel schneller den Fix für dieses Problem ausliefern.
Viele Grüße,
John
Bei einer Synchronisation von TB 60.x auf 68.x RC taucht der Fehler auf, egal ob Cardbook oder Tb Adressbuch.
Entschuldigung, wenn ich nochmal nachfrage:
1. In Cardbook in TB60 einen Kontakt gelöscht
2. Zur Kontrolle in TB60 mit Tbsync gelöscht: Wie erwartet wird der Kontakt im lokalen TbSync Adressbuch gelöscht.
3. Auf TB68 gewechselt und dort ebenfalls mit TbSync synchronisiert: Fehler 412.
Ist das 100% reproduzierbar? Darf ich ein DebugLog von dem Fehler haben? Dazu:
- unter "Hilfe" im TbSync Manager das Debug logging aktivieren
- TB68 neu starten
- in den erweiterten Thunderbird-Einstellungen den Schlüssel "extensions.tbsync.log.userdatalevel" auf 9 setzen (das kommt bald auch ins UI)
- versuchen den Fehler zu reproduzieren
- unter Hilfe im Account Manager einen BugReport erstellen.
- du kannst des Debuglog vor dem Abschicken noch zurechtstutzen, wenn es zu viele Infos enthält, die ich nicht sehen soll.
Nochmals vielen Dank für deine Tests!
Hallo EDV-Oldi,
dein Test war doch aber: Kontakt in Cardbook (in TB60) verschieben und dann das gleiche Account in TB68 mit TbSync syncen oder? Wo war da TbSync 1.7.x involviert? Aber es ist glaube ich eine gute Idee, TbSync 1.7.x für die Tests nicht zu benutzen, um nicht ein verfälschtes Bild zu bekommen.
Zu dem Fehler, war das wirklich ein "402"? Das heißt "Payment Required" und das hab ich echt noch nie gesehen.
Könnte ich auf dem Server, auf dem das passiert ist, ein Testkonto haben?
Wenn du übers Wochenende zunächst erstmal den alten Code rauswirfst, könnte ich am Montag den grundlegenden Umbau hin zu async function machen (den du für fetch() zwingend brauchst). Das ist nicht sehr viel, aber es zu erklären würde länger dauern, als es zu machen.
Hallo EDV-Oldi,
Wenn Du jetzt noch das TbSync-Symbol statt den Text einsetzt, finde ich das auch noch etwas auffälliger.
Das muss ich mir angucken, aber da für TB76 eh wieder alles ganz anders wird, werde ich das jetzt wahrscheinlich nicht ändern. Mal gucken.
Dann noch eine Anmerkung zu dem Text der beim Neustart von TB unten erscheint.
Wer von den normal User weiß wann das Update auf TB 68.x kommt?
Die beenden Thunderbird und beim nächsten Start ist die neuen Version da.Kannst Du nicht in der neuen Version eine Funktion einbauen, die beim ersten Start in TbSync alle Konten Deaktiviert?
Ja, das ist echt schwierig. Ich habe lange versucht eine automatische Migration hinzubekommen, aber das ist ECHT schwierig und es ist nicht auszuschließen, dass ich dabei Daten der Nutzer kaputt mache. Es hat sich so viel unter der Haube verändert. Das Risiko war mir am Ende einfach zu hoch. Als absehbar war, das ich nicht migrieren kann, bin ich dann sogar mit der Axt durch den Code und habe ganz viele alte Sachen rausgehauen, die ich schon ewig mit mir rumgeschleppt habe. Und das war gut, der Code ist jetzt viel sauberer.
Deswegen erzwinge ich jetzt tatsächlich eine neue Synchronisation mit TB68 und deaktiviere alle Konten, wie du vorgeschlagen hast.
Das Problem: Sollte eines dieser Konten vor dem Upgrade auf TB68 mit dem Server nicht synchronisiert sein, darf ich die lokalen Kalender/Adressbücher ja nicht einfach löschen (was eigentlich bei jeder Kontodeaktivierung gemacht wird), weil dann würde ich ja evtl. Daten vernichten. Also lasse ich bei der erzwungenen Kontodeaktivierung alle Objekte aber markiere sie als "getrennt":
Wenn der User dann seine Konten neu aktiviert, werden alle seine Resourcen neu erstellt und dann hat er sie quasi doppelt. Ich bin auf der sicheren Seite, weil ich keine Daten lösche, aber der User muss nun selber gucken, ob und welche Daten er evtl von Hand übernehmen muss. Genau dass kann er vermeiden, wenn er die Konten selber vor dem Upgrade synct und deaktiviert.
Thunderbird 68 wird zu Beginn nicht per Auto Update verteilt, das passiert erst mit dem ersten Point Release. Am Anfang kann der User also selber bestimmen, wann er zu TB68 wechselt.
Ist alles nicht schön, aber besser hab ich es nicht hinbekommen.
ist es möglich das Symbol von TbSync links neben den Tagesplan zu legen?
Hab es mal nach links geschoben (1x Beta-Release-Channel Addons aktualisieren).
Mir persönlich gefällt es am rechten Rand aber besser. Hm. Mal gucken ob ich mich dran gewöhne.
Um an die Attachment Größe zu kommen, hab ich das hier als Vorlage genommen.: https://searchfox.org/comm-central/s…HdrView.js#1806
Bei meinen Tests hat das funktioniert, aber es gibt noch offene Fragen.
Zunächst habe ich eine weitere Methode von AEMessage definiert:
AEMessage.prototype.getAttSize = async function(_url, isExternalAttachment, isLinkAttachment = false) {
let url = _url;
let size = 0;
let options = { method: "HEAD" };
// NOTE: For internal mailbox, imap, news urls the response body must get
// the content length with getReader().read() but we don't need to do this
// here as libmime streams it already in addAttachmentField(). For imap or
// news urls with credentials (username, userPass), we must remove them
// as Request fails such urls with a MSG_URL_HAS_CREDENTIALS error.
if (url.startsWith("imap://") || url.startsWith("news://")) {
let uri = Services.io.newURI(url);
if (uri.username)
url = url.replace(uri.username + "@", "");
if (uri.userPass)
url = url.replace(uri.userPass + "@", "");
}
let request = new Request(url, options);
await fetch(request)
.then((response) => {
if (!response.ok) {
return null;
}
if (isLinkAttachment) {
if (response.status < 200 || response.status > 304) {
return null;
}
}
return response;
})
.then(async (response) => {
if (isExternalAttachment) {
size = response ? response.headers.get("content-length") : 0;
} else {
let data = await response.body.getReader().read();
size = data.value.length;
}
})
.catch((error) => {
console.warn("getAttSize: error - " + error.message);
});
return size;
};und hier eingefügt:
https://gitlab.com/ThunderbirdMai…_window.js#L883
Aufgerufen hab ich diese Funktion dann zwischen Zeile 897 und 898, also hier:
https://gitlab.com/ThunderbirdMai…_window.js#L898
mit dieser Zeile:
this.getAttSize(attachment.url, attachment.isExternalAttachment).then(function(size) { console.log("Size: " + size); });
Das ist jetzt erstmal nur zum Testen, ob du damit für die verschiedenen Attachment Typen an die richtige Größe kommst.
1. Die Methode die ich als Vorlage benutzt habe, kennt isLinkAttachment, dein AddOn scheint das nicht zu kennen, hab es daher per default auf false gesetzt. Sagt dir isLinkAttachment was?
2. Durch fetch() ist die neue getAttSize Methode async, daher auch der Aufruf mit .then(). Kennst du async/await und Promises? Im Prinzip gabelt sich der Programmablauf durch this.getAttSize() auf, der Aufruf wird in den Hintergrund geschoben und sofort die nächste Zeile (899) abgearbeitet. Irgendwann ist die async Funktion im Hintergrund fertig und führt dann die im then() angegebene Funktion aus. Ähnlich wie ein setTimeout, nur das der Callback nicht nach einer bestimmten Zeit ausgeführt wird, sondern wenn eine andere Funktion fertig ist.
Wenn du damit die richtigen Größen bekommst, und du sicher bist, dass du dann nur noch die Thunderbird eigenen Funktionen und z.B. nicht mehr saveAttachmentToFolder benutzen willst, dann wäre es glaube ich gut, den ganzen Kram dann wirklich zu entfernen (neuer branch im gitlab) und in der reduzierten Version dann echte async Funktionen zu benutzen - oder alles nach dem Aufruf von getAttSize in den .then() zu stopfen, aber das wird so unleserlich...
Erstmal is wichtig, bekommst du den Zeitstempel (mein vorletzter Post) und die Größe und könntest somit den alten Kram rauswerfen?
Überall wo du Zugriff auf aewindow.currentTask hast, kannst du via aewindow.currentTask.getMessageHeader() auf die Header Daten der Email zugreifen (https://developer.mozilla.org/en-US/docs/Moz…BHdr#Attributes)
In AEMessage.prototype.saveAtt kannst du direkt als erstes, also hier
https://gitlab.com/ThunderbirdMai…_window.js#L885
mal folgendes einfügen
console.log(aewindow.currentTask.getMessageHeader().subject + " : " + aewindow.currentTask.getMessageHeader().dateInSeconds)
und bekommst für jede Mail den gesuchten Timestamp.
Hilft das?
Also sollte ich eher veruchen über die TB funktionen Attachment Größe und Datum zu erhalten, damit die alte Funktion gelöscht und die Einstellungen vereinfacht werden können. Richtig?
Ich versuche mich gerade einzulesen.
Kannst du kurz erklären, was konzeptionell der Unterschied zwischen aeMessenger.saveAttachmentToFolder und aewindow.messenger.saveAttachmentToFile ist, und warum der erstere ein file Objekt zurückgibt und das originale file Objekt des Attachments überschreibt?
aeMessenger.saveAttachmentToFolder ist die Funktion, die am Ende die problematische startupUrl Funktion aufruft, richtig?
Trennen beide Funktionen auch das Attachment ab (also löschen es aus der Mail?) . Wo passiert das?
Danke und viele Grüße
John
Die Reihenfolge ist alphabetisch, und da der AccountName als prefix benutzt wird, kannst du den als grobe Sortierung benutzen:
- account deaktivieren
- account umbenennen
- account aktivieren
Eine Änderung des AccountNamens wärend das Account aktiviert ist hat keine Auswirkung auf die bereits angelegten Adressbücher. Daher einmal aus und wieder an.
Du kannst einfach den von Mozilla (ATN) nehmen, der CatMan ist nicht Teil des beta-release-channels.
EAS ist mein Provider für ExchangeActiveSync (outlook.de, office365 und andere)
Ich teste weiter.
Seit heute wird in der TB60 Version ein Banner eingeblendet, das ich empfehle, vor einem Update auf TB68 alle TbSync Konten zu synchronisieren und dann zu deaktivieren und nach dem Update auf TB68 diese wieder zu aktivieren. Das wurde vor ca 1h auf ATN freigeschaltet.
Hast du das bereits gesehen/gemacht? Wenn nicht, empfehle ich in TB68 alle Adressbücher/Kalender, die von TbSync verwaltet werden, im Thunderbird Adressbuch bzw. in Lightning zu löschen, danach alle TbSync Konten zu deaktivieren, neu zu aktivieren und dann sauber neu zu synchronisieren.
Danke fürs Testen!