Wenn der Mauszeiger über der Zeile eines Kalenders steht, wird rechts in der Zeile ein Augen-Symbol angezeigt. Klicke darauf, um den Kalender auszublenden. Das Auge wird dann durchgestrichen und bleibt dauerhaft sichtbar – bis der Kalender mit einem weiteren Klick darauf wieder sichtbar gemacht wird.
Die Farbe des Kalenders ist weiterhin links vom Kalendernamen zu sehen – nur jetzt eben rund statt quadratisch.
Thunderbird 78 standardmäßig nur noch 1.3 und neuer akzeptiert
Du meinst TLS 1.2 und neuer, oder habe ich was verpasst?
Der Kalener ist mit CalDAV eingebunden, ist ein lokaler Owncloud-Server.
Prinzipiell unterstützt CalDAV das Senden von E-Mails über den Server. Ob und wie man das bei Owncloud einrichten muss, weiß ich nicht. In jedem Fall wird Thunderbird keine E-Mails senden, solange es davon ausgeht, dass der Server sich um den Versand von E-Mails kümmert. Wenn die Mails also bei einem lokalen Kalender korrekt versendet werden, und es nur im CalDAV-Kalender Probleme gibt, liegt die Ursache vermutlich beim Server.
Gibt es denn eine Möglichkeit, dass der Kalender mit mehreren Geräten synchronisiert wird und man dann auch die Einladungen verschicken kann?
Ich bin der Entwickler des dezentralen Synchronisationstools GeneralSync, damit ist das auch ohne Server möglich (einschließlich komplexerer Fälle wie "Antwort auf Einladung wird auf einem anderem PC empfangen"). Für Thunderbird 78 arbeite ich diesbezüglich noch an ein paar Fehlerbehebungen, die vermutlich größtenteils in den kommenden Stunden bis Tagen veröffentlicht werden.
Ich vermute, dass auch andere Synchronisationslösungen zumindest in einfachen Situationen ebenfalls funktionieren sollten, teste aber nur meine eigene Software und kann das daher nicht direkt bestätigen.
seit wann wird das eingetragen?
Keine Ahnung, da ich aber ohnehin gerade am Testen von Einladungen in 78 war habe ich kurz in den Gesendet-Ordner geschaut, und da waren die Mails drin. In meinem 68-er Profil auf der Empfangsseite ebenfalls. Also wenn sich das geändert haben sollte, dann mit oder vor 68.
Eventuell im Zusammenhang mit dem Abschaffen der Rückfrage, ob Mails gesendet werden sollen? Das war glaube ich in 68, bin mir aber da gerade nicht mehr sicher – könnte auch 60 gewesen sein.
Edit: Entschuldigt das Doppelposting – ich war nebenher am Testen von Einladungen in diversen Varianten und habe daher die vorherigen Nachrichten nicht gesehen, bevor ich diese Nachricht abgeschickt habe.
Die Einladungsfunktionen von Thunderbird 78 entsprechen denen aus Thunderbird 68:
Kann man festlegen, worüber Thunderbird den Termin dann verschickt?
In den Kalender-Einstellungen (Rechtsklick auf den Kalender in der Liste links im Kalender-Tab) kann man für jeden Kalender einzeln bestimmen, welche E-Mail-Adresse für Einladungen verwendet werden soll. Mit dieser E-Mail-Adresse wirst du dann auch als "Organisator" in den Termin eingetragen (sofern du das nicht von Hand änderst).
Nur habe ich festgestellt, dass der Teilnehmer die Einladung gar nicht erhält bzw. nicht von Thunderbird verschickt wird.
Ob eine Einladung per Mail verschickt wird, wird individuell für jeden einzelnen Termin geregelt: unter der Liste der Teilnehmer gibt es dafür eine Checkbox ("Teilnehmer benachrichtigen"). Ob eine Mail gesendet wird, erkennt man auch an der Schaltfläche "Speichern und Schließen" in der Toolbar: wenn eine Mail gesendet wird, wird sie durch eine "Senden und Schließen"-Schaltfläche ersetzt.
Ich hab den Termin auch nirgendwo im Postausgang/Gesendet gesehen
Sobald eine Mail gesendet wurde, wird Thunderbird auch bei den automatisch erzeugten Termin-Mails eine Kopie im Gesendet-Ordner speichern.
Ich habe mir den Server im konkreten Fall nicht angeschaut, aber eine weitere mögliche Ursache: Thunderbird 78 unterstützt in der Standardkonfiguration ausschließlich TLS 1.2 oder neuer. Wenn der Server also noch die deutlich älteren Standards TLS 1.0 oder 1.1 oder gar SSL 3.0 einsetzt, kann der Server nicht mehr direkt mit Thunderbird genutzt werden. Leider gibt es dazu aber keine individuellen Fehlermeldungen, daher sind diese Probleme schwer zu erkennen.
Saubere Lösung: bitte den Provider, die dafür notwendigen Sicherheitsupdates auf seinem Server einzuspielen. Dann sollte Thunderbird wieder wie gewohnt funktionieren.
Unsaubere Kurzzeit-Lösung mit massiven Sicherheitsimplikationen: informiere dich über die Probleme mit der besten vom Server unterstützten TLS-Version. Wenn du alle Nachteile dieser Versionen für alle Verbindungen und mit allen Servern akzeptierst, kannst du in about:config das Feld 'security.tls.version.min' auf einen kleineren Wert stellen (iirc '1' für TLS 1.0, '2' für TLS 1.1). Schreibe dir deine Änderung irgendwo auf und mache sie sofort rückgängig, sobald der Provider eine aktuellere TLS-Version unterstützt oder du den Provider gewechselt hast.
Mozilla fast 24 Monate vor der Veröffentlichung von Firefox "Quantum" (= Version 57) die Einführung der Webextensions und das Ende der klassischen XUL-Erweiterungen angekündigt hatte
Wichtiger wäre gewesen, bereits zu diesem Zeitpunkt (oder wenigstens ein paar Monate vor Quantum) die APIs fertigzustellen, die die Entwickler dann nutzen sollen. Nur mit einer Ankündigung ohne konkrete API kann man als Entwickler auch nicht viel tun, außer eventuell aufgeben. Die tatsächliche Vorbereitungszeit für Quantum war – zumindest für manche Add-ons – negativ, da APIs erst nach der Quantum-Umstellung bereitgestellt wurden. Manchen Add-ons fehlen bis heute APIs – und das wird sich prinzipbedingt auch niemals ändern.
Das alleine wäre kein Problem, aber mögliche Workarounds (z.B. Experimente) wurden von Mozilla ohne technische Notwendigkeit bewusst gesperrt – zumindest in einer Übergangsphase Experimente zuzulassen hätte imho niemandem einen Zacken aus der Krone gebrochen. Daher finde ich die Kritik an Mozilla sehr gerechtfertigt – und kann bis heute nicht erkennen, dass Mozilla mit Add-on-Entwickern einen Dialog auf Augenhöhe führen würde. Mozilla entscheidet alleine, welche Add-ons "gut" sind (und daher APIs bekommen) und welche nicht. Das kann man positiv ("Mozilla weiß es sicher besser") oder negativ sehen ("Mozilla bildet sich ein, alles besser zu wissen") – ich persönlich tendiere zu letzterem.
Bei Thunderbird läuft das besser, Kommunikation und Dokumentation fehlt zwar hinten und vorne (und das kann vergleichbaren Entwicklerschwund verursachen wie Quantum...), aber wenigstens werden die Probleme der Add-on-Entwicker wahrgenommen und es gibt (zumindest derzeit noch) voll funktionsfähige Workarounds.
Übrigens macht sich bei Thunderbird – zumindest in der bislang verfügbaren Dokumentation – auch niemand vor, dass WebExtensions keine Updates mehr brauchen. Die Hoffnung ist nur, weniger und einfachere Änderungen zu erfordern als das derzeit notwendig ist. Add-on-Entwickler werden also auch nach der Umstellung nicht plötzlich arbeitslos 
Oder kann ich einen Kalender nur für meine Aufgaben einrichten?
Lokale Thunderbird-Kalender können sowohl Termine als auch Aufgaben enthalten. Es ist aber nicht ohne weiteres möglich, selbst angelegte Kalender nur auf Aufgaben einzuschränken.
Neue lokale Kalender können z.B. über einen Rechtsklick in der Kalenderliste links im Kalender-Tab angelegt werden.
Ich spreche nicht von den Codes und Scripts, sondern von den Erweiterungen, die nicht mehr funktionieren und von den Entwicklern, wie etwa Thunder nicht weiterentwickelt werden... [...]
Nur kurz zu meinen Add-ons: Minimize on Close hast du ja schon gefunden, Rise of the Tools ist am gleichen Tag ins Review gegangen und sollte also auch bald kommen. LightningButton werde ich voraussichtlich aufgeben, da es inzwischen die allermeisten Funktionen direkt in Thunderbird gibt – das Add-on hatte ja angefangen, als Lightning noch keine eigenen Toolbar-Buttons mitgeliefert hat. Die "offiziellen" Toolbar-Buttons sind aber natürlich im aktuellen Design, insofern kann ich etwas Sentimentalität durchaus verstehen 
Das GeneralSync-Integrations-Add-on ist ein sehr viel komplexeres Biest, da bin ich noch dran. Auch in Vollzeit wird das bis zum Release eng, aber noch habe ich Hoffnung
Leider lässt auch die Dokumentation der neuen WebExtensions APIs meiner Meinung nach sehr zu wünschen übrig.
Das wird in diesem Thread eventuell schnell OT, aber das ist auch aus meiner Sicht eines der großen Probleme. Ich habe dementsprechend begonnen, einen groben Leitfaden für die Portierung von legacy-Add-ons zu schreiben (Text, Pull Request). Mein Ziel war es, damit einen Überblick über die notwendigen Portierungsarbeiten zu bekommen, um dann bei der eigentlichen Portierung bessere Entscheidungen treffen zu können. Vermutlich also nicht exakt was du suchst, enthält aber viele Links zu Referenz-Artikeln, teils mit Beispielen.
Ich versuche das im Verlaufe meiner Portierungsarbeit noch etwas auszubauen – es fehlt derzeit mindestens noch ein Absatz zum Ersetzen von Add-on-Einstellungen. Vielleicht werde ich auch daneben noch ein paar fertige Beispiel-Experimente veröffentlichen, die in vielen Add-ons nützlich sein könnten, z.B. zur Migration alter Einstellungen o.ä.. Sowas macht aber erst Sinn, wenn ich mit dem Portieren von GeneralSync weiter gekommen bin.
Ich würde mich natürlich auch freuen, wenn andere den Artikel weiter ergänzen 
Da nach Thunderbird 78 vermutlich die WebExtension-Experiments gar nicht mehr möglich sein werden, ist dann sowieso Ende für meine Extensions
Ich sehe noch nicht, dass das Thunderbird-Team wirklich einen derartig nutzerfeindlichen Schritt unternehmen wird, aber ich kann auch nicht sagen das mich die derzeitige Kommunikation diesbezüglich beruhigen würde. Ich habe inzwischen mit dem Portieren meiner Add-ons begonnen und daher langsam einen groben Überblick über die aktuelle Situation – ohne Experiments wird imho derzeit kaum ein Add-on auskommen und die Dokumentation ist definitiv noch ausbaufähig. Zumindest mit Experiments geht aber mehr als ich erwartet hätte, sogar die XPCOM-Registry bleibt zugänglich. Letzteres ist aber auch bitter nötig, da das versprochene neue Adressbuch (noch?) fehlt und der Kalender keine API hat...
Rein technisch beleibt in Add-ons für 77.0b3 also alles machbar, was in vorherigen Versionen machbar war, auch wenn vieles neu geschrieben oder zumindest stark angepasst werden muss. Ohne Experimente wären alle regelmäßig von mir genutztes Add-ons dagegen überhaupt nicht umsetzbar. Ich würde hoffen, dass neue APIs den Experiment-Teil mit jeder Thunderbird-Version sukzessive verkleinern – aber es wird noch viele Jahre (Jahrzehnte?) dauern, bis die Mehrheit der Add-ons ohne Experimente auskommt.
Ich konnte keinerlei Bereitschaft auf BugZilla sehen, dass jemand zukünftig passende APIs vielleicht erstellen würde.
Wenn ich die bisherige Kommunikation richtig verstanden habe, sollen Add-on-Entwickler selbst konkrete APIs implementieren (als Experiment) und zunächst im eigenen Add-on nutzen. Die Experimente sollten dann in der Bugzilla als Vorschlag/Diskussionsgrundlage eingebracht werden. Ich kann verstehen, wenn das Thunderbird-Team einen solchen "Machbarkeitsbeweis" sehen will, bevor sie sich eingehend damit beschäftigen (schließlich gibt es haufenweise Bugs, die bis zur Veröffentlichung gefixt werden müssen) – andererseits aber auch, dass der dafür notwendige Aufwand das Budget vieler Add-on-Entwickler übersteigen dürfte.
Ich will dich aber nicht von deinem Kurs abbringen: die Zukunft war schonmal rosiger und die Situation ist von "perfekt" meilenweit entfernt. Ich kann deine Entscheidung sehr gut nachvollziehen – schließlich ist das Portieren ist sehr zeitintensiv und schon die reguläre Pflege von Add-ons ist eine undankbare Angelegenheit. In diesem Sinne danke für deinen Beitrag zum Thunderbird-Ökosystem!
Build mit integriertem OpenPGP.
Sobald das in einem testfähigen Zustand ist, sollte das auch über Treeherder kommen (bug 1628424). Derzeit enthält comm-central laut Bugzilla noch nicht alle Abhängigkeiten um den neuen Code nutzen zu können, klingt also so als wäre auch das selbst bauen noch nicht sinnvoll. Bislang erhält man mit damit wohl nur ein Thunderbird mit einigen internen Änderungen für OpenPGP, aber ohne nutzbare OpenPGP-Funktionen.
" deleted.sqlite "
Diese Datei enthält keine gelöschten Termine, sondern nur ein paar Metadaten. Es ist also nicht direkt möglich, gelöschte Termine wiederherzustellen.
Kann man abgelaufene Termine automatisch so löschen, daß darin enthaltene Wiederholungen erhalten bleiben ?
Man kann prinzipiell beliebige Einzeltermine einer Serie löschen: einfach die gewünschten Instanzen / Einzteltermine im Kalender markieren und via Rechtsklick und "Termin löschen" löschen (oder die Entfernen-Taste drücken). Die Rückfrage bezüglich der Terminserie sollte dann mit "Nur diesen Termin löschen" beantwortet werden – sonst werden auch zukünftige Termine gelöscht.
Eine automatische Löschung von Terminen ist meines Wissens aber nicht vorgesehen – bei Bedarf müssen Termine also von Hand gelöscht werden. Ich wüsste aber auch nicht, warum man Termine automatisch löschen wollen würde. Je nachdem was du mit der Löschung bezweckst, gibt es aber eventuell einen anderen Lösungsweg?
Vielleicht gibt es ja wirklich praktikable Anleitungen?
Ich habe TB > 68 bislang nicht gebaut, aber das Bauen von Thunderbird 68 ist unter Linux ziemlich einfach – wenn man Mercurial, einen Kompiler und übrige Abhängigkeiten installiert hat. Der offizielle Weg wäre für die aktuellste Alpha ein Sechszeiler:
hg clone http://hg.mozilla.org/comm-central # herunterladen von comm-central, das Alpha-Repository u.a. von Thunderbird
cd comm-central # in das heruntergeladene Verzeichnis wechseln
python client.py checkout # herunterladen weiterer Abhängigkeiten
echo "ac_add_options --enable-application=mail" > .mozconfig # Thunderbird auswählen
echo 'ac_add_options --enable-calendar' >> .mozconfig # Lightning hinzufügen
./mozilla/mach build # Thunderbird kompilierenWobei die Zeile für Lightning eventuell inzwischen nicht mehr nötig ist – habe wie gesagt mit den aktuellen Versionen nicht probiert. Ich habe auch nie den offiziellen Weg getestet da ich die Abhängigkeiten selbst verwalten will. Aber das Prinzip sollte stimmen
Wobei man eigentlich nur selbst bauen muss, wenn man besondere Bedürfnisse hat. Für Standardfälle gibt es automatische Builds im Treeherder. Download z.B. durch Anklicken von einem grünen "B" neben einer kompatiblen Platform (Windows / Linux / OSX), die Dateien gibt es dann unten unter "Job Details". Für einen Linux-Build wäre z.B. die passende Datei dort i.d.R. "target.tar.bz2", für Windows vermutlich "setup.exe" und von OSX vermutlich "target.dmg" (?). Ist nicht für Endbenutzer gedacht, daher bedient es sich nicht sonderlich intuitiv...
Ich kann das Problem reproduzieren und erinnere mich auch dunkel, damit schonmal zu tun gehabt zu haben. Ich kenne aber spontan auch keine schnelle Lösung.
Es handelt sich vermutlich um eine Variante von Bug 1584222. Von den Entwicklern hat sich aber bislang niemand dazu geäußert. Ich würde vermuten, dass der Fehler irgendwo zwischen Datenbank und Anzeige sitzt (und sich also ohne Datenverlust beheben lässt), aber sicher bin ich natürlich nicht...
Wundert mich aber, das nicht mehr Leute das Problem haben
Alle Programme machen doch genau das was sie sollen – es gibt durchaus Leute die ausfallende Serientermine als abgesagt markieren wollen (und vermutlich auch einige die Serientermine nicht nutzen und daher auch nicht betroffen sind). Auch wenn ich eine Option zum gelegentlichen "echten" Löschen eines Termine zugegebenermaßen auch schön fände, empfinde ich das nicht wirklich als Problem.
Oder meinst du die blassen Termine? Wie gesagt, die kenne ich ausschließlich von einer einzelnen, alten, fehlerhaften Kalender-App von Samsung. Alle anderen von mit getesteten Kalender-Apps haben – zumindest mit GeneralSync als Synchronisations-Backend – dieses Problem nicht.
Aber habe es hier eine Lösung?
Nimm eine Kalender-App die Serientermine löschen kann oder frage bei deiner bestehenden Kalender-App an, ob man diese Funktion hinzufügen könnte. Auf Anhieb fällt mir da zwar keine ein, aber das Problem hat nichts mit Thunderbird (oder der Synchronisation) zu tun.
Und dann bleiben noch die blassen Termine
Hatte ich überlesen... "blass" bedeutet vorläufig. Die Frage ist nur, warum die Termine als "vorläufig" markiert werden.
Ich kenne einen Bug in der Standard-App S-Planner auf alten Samsung-Geräten: dort wurden neue Termine immer als vorläufig eingestuft. Bei Änderungen passierte das aber – zumindest mit GeneralSync – meiner Erinnerung nach nicht. Da bei CalDAV-Änderungen nicht immer alle Daten übernommen werden können, kann es aber durchaus sein dass sich das mit anderen Synchronisationsmethoden anders verhält.
Eine andere Kalender-App kann eventuell helfen (z.B. Etar).
Kann es sein, dass es um einen Serientermin geht?
Viele Android-Kalender-Apps können einzelne Termine aus einer Serie nicht löschen, sondern markieren diese stattdessen als "abgesagt". Abgesagte Termine sind weiterhin im Kalender vorhanden (auch wenn sie von allen mir bekannten Android-Kalender-Apps nicht angezeigt werden) und werden in Thunderbird durchgestrichen dargestellt.
(Disclaimer: Ich nutze kein CalDAV – meine Erfahrung kommt von der direkten Synchronisation via GeneralSync, ohne die Daten über einen Server laufen zu lassen. Es könnte also auch ein CalDAV- oder Server-spezifisches Problem sein, dann kann ich nicht helfen.)
Wie kann man im TB Kalender die Termin Kategorien bearbeiten und neue dauerhaft speichern?
Die Liste der dauerhaft gespeicherten Kategorien befindet sich in den regulären Einstellungen¹ von Thunderbird unter "Kalender" (Kalender-Symbol in der Leiste links), als separater Tab "Kategorien". Die Kategorien bereits erfasster Termine werden dabei nicht verändert, die Liste dient nur der Anzeige in Thunderbird.
_____
¹ je nach Betriebssystem und Ansichtseinstellungen erreicht man die regulären Einstellungen via "Menü | Einstellungen | Einstellungen", "Menüleiste | Extras | Einstellungen" oder "Menüleiste | Bearbeiten | Einstellungen".
Hier konnte ich jedoch noch keine Option/Kombi finden, die mir das XPCOM zugänglich machen könnten.
Das wird es auch niemals geben, soviel wurde bereits beschlossen. Wenn du "alles" machen können willst (was XPCOM ja zulässt), brauchst du ein Experiment (das sollte dann auch irgendwie als "Berechtigung" dem Nutzer angezeigt werden, auch wenn es technisch keine Berechtigung ist).
Ist das tatsächlich ein Pferd, auf das man langfristig setzen kann?
Nein, soll es auch nicht sein. Rechne damit, dass das Experiment für jede ESR-Version vollständig neu geschrieben werden muss. Daher soll man es ja auch klein halten.
Gibt es einen sinnvollen Zugang zu diesen "Experimenten", so dass ich mir die Entwicklung, API etc. anschauen kann, um es als mögliche Option in betracht zu ziehen?
Ist zwar eigentlich für Firefox, aber ich würde zuerst die offizielle Übersicht unter https://webextensions-experiments.readthedocs.io/en/latest/ lesen und anschließend das dort verlinkte crashme anschauen. Dann sollte man loslegen können.
Beim Lesen der Übersicht nicht erschrecken: in Firefox-Beta und -Release sind Experiments bewusst gesperrt (d.h. Mozilla verbietet Drittentwicklern, Experiments zu veröffentlichen) – für Thunderbird ist eine solche Sperre meines Wissens bislang nicht geplant.
Edit: es gibt eine offizielle Dokumentation für Thunderbird. Frag mich nicht warum ich die gerade übersehen habe...
