TB 78.7.0 Ein erster Eindruck

Zitat von Stylist

Die bereits aus TB 68 bekannten Fehler im Kalender sind weiterhin vorhanden.

Ich hatte auch gedacht, die Version würde einige Fehler im Kalender beheben. Ist aber nicht so. In den Release Notes ist der Kalender nicht erwähnt. Demnach wurde da nichts verändert.

Zitat von Stylist

Inzwischen kann ich keinen Termin per Drag & Drop verschieben, springt nach Neustart des TB zurück auf Originaldatum.

Es kann nur besser werden!

Hoffentlich

Stylist

Hallo,

zum Thema "Drag&Drop": Seit TB 78.0 funktioniert bei mir der Drag&Drop von eingehenden .ics-Dateien in den Kalender nicht mehr. Bislang konnte ich die .ics-Datei ganz einfach mit der Maus nach rechts zum Tagesplan schieben, loslassen und der Termin wurde mit allem Inhalt geöffnet. Mit Speichern hatte ich ihn dann im Kalender. Wenn ich das nun mache, öffnet sich zwar weiterhin das Termin-Fenster, aber ohne den eigentlichen Angaben aus der .ics.Datei.

Kennt jemand dieses Problem und hat eine Lösung dafür?

Vielen Dank und Gruß

McGuh

Zitat von Stylist

1. Falsche Nummerierung der Wochentage in mehreren Monaten (Sommerzeit?) in verschieden Jahren, z.B. 1978, in den beiden Ansichten 'Mehrere Wochen' und 'Monat' auch noch unterschiedlich.

Das ist bekannt, Bug 1673835. Ursache sind wohl tatsächlich Zeitzonendetails, der Bug tritt entsprechend nur vor 2018 auf. Da die meisten Nutzer eher mit aktuellen Terminen hantieren, hat das vermutlich noch keinen Freiwilligen so sehr gestört das dieses Ansichtsproblem behoben wird.

Zitat von Stylist

a) Einen Folgetermin mit Drag & Drop auf ein anderes Datum verschoben

b) Einen Folgetermin mit 'Ausschneiden' und 'Einfügen' in an anderes Datum

c) Einen Folgetermin mit 'Kopieren' in anderes Datum und anschließend Ursprungstermin gelöscht

In deinen Fällen b und c legst du jeweils eine neue Instanz des Termins an, die nicht mehr mit dem Ursprungstermin verknüpft ist. Da dieser neue Termin aber Teil einer Terminserie sein muss um angezeigt zu werden legt Thunderbird dann einen neuen, leeren Ursprungstermin an. Es ist also gewollt, dass "Alle Termine Bearbeiten" in Szenarien b und c keine Daten anzeigt – schließlich sind alle Bestandteile des Termins logisch gesehen eine Ausnahmeregel!

Mir ist bewusst das das für einige Nutzer nicht intuitiv ist, aber es ist die beste Lösung wenn man den Termin authentisch kopieren will. Man kann aber sicherlich darüber streiten, ob statt einer echten Kopie nicht lieber ein neue Termin mit gleichem Inhalt, aber ohne Terminserie angelegt werden sollte. Dann verliert man die Information über die Terminserie, aber gewinnt an Benutzerfreundlichkeit für Änderungen.

Das Verschwinden des Ortes scheint mir aber wirklich ein Bug zu sein, hängt aber von weiteren Faktoren ab (eventuell: nur lokale Kalender bzw. nur durch Thunderbird bereitgestellte Kalender?). Zumindest trat das Problem in meinen Tests mit GeneralSync-Kalendern nicht auf.

Das hier auf Drag-And-Drop geschobene Problem der nicht persistenten Termine ist aber wirklich gravierend, und weitreichender als es sich anhört: in meinen Tests scheint immer nur die erste Ausnahmeregel an einem Serientermin gespeichert zu werden, egal auf welchem Wege diese angelegt wurde. Scheint ein Backendproblem zu sein (d.h. in der Datenbank), und trifft damit auch GeneralSync, wenn auch in anderen Zusammenhängen.

Kann aber noch nicht sicher sagen woran das liegt. Gespeichert wird scheinbar alles ordentlich, insofern hoffentlich ein Problem das ohne Datenverlust behoben werden kann.

Hallo generalsync,

Danke für das rein schauen in diesen Beitrag und die gute Erklärung.

Gruß
EDV-Oldi

Zitat von Stylist

Dann macht es aber keinen Sinn 'Alle Termine bearbeiten' anzuzeigen, dieser Punkt sollte zumindest inaktiv gesetzt werden.

Wenn du konkrete Lösungen beitragen willst, würde es Sinn machen einen entsprechenden Bug zu öffnen und dort mögliche Problemlösungen vorschlagen. Wenn es dir besonders dringend unter den Nägeln brennt und du nicht warten kannst/willst bis sich jemand anderes darum kümmern könntest du dann auch – sobald du das OK für eine dieser Lösungen bekommst – selbst einen Patch entwickeln (oder einen Entwickler anstellen, der das für dich tut). Hier darüber zu diskutieren wird aber vermutlich keine schnellere Veränderung bewirken.

Wenn du dafür Begriffe suchst: die neu erzeugten, leeren Elterntermine heißen "faked master events" und werden in Bugzilla auch als "X-MOZ-FAKED-MASTER event" bezeichnet, nach dem internen Eigenschaftsnamen, der diese Termine kennzeichnet.

Zitat von Stylist

Beim Versuch, fehlende Angaben zu ergänzen wird man scheitern, man darf Eingaben zwar machen, aber nach TB-Neustart ist wieder alles verschwunden!

Wirklich kein Datenverlust?

Dem Anschein nach hakt es am Laden, nicht am Speichern. Wenn dieser Anschein nicht trügt und der Bug gemeldet, gefunden und behoben wurde, sollten deine "verschwundenen" Eingaben also wieder erscheinen.

@Stylist

Falls du einen Bug eröffnest, überprüfe mal folgende Tests bei dir. Vielleicht hilft es, einem vermuteten Bug auf die Spur zu kommen. Ich habe sie mit der 78.7.0 unter Win 10 1909 ausgeführt. Der Cache war, entgegen meiner Gewohnheit, an. Ohne habe ich nicht getestet.

Ich habe deine Tests auf einem CalDAV in der NC durchgeführt. Die Ergebnisse sind nicht konsistent in Bezug auf Drag&Drop und Cut%Paste.

Folgende Unterschiede habe ich beobachtet:

Ort:

Drag&Drop: Der Ort wird im verschobenen Termin nicht mehr angezeigt. Wenn man den Kalender exportiert, ist er zunächst noch in den Daten. Allerdings nur für den Thunderbird. (Cache?)

Auf der NC ist LOCATION bereits gelöscht. Folgerichtig ist der Ort nach einem Neustart auch im Thunderbird leer.

Cut&Paste: Der Ort wird im verschobenen Termin nicht mehr angezeigt. Er fehlt hier auch bereits gleich im Export.

Für die Beschreibung und die Kategorie habe ich vergessen, das auch zu kontrollieren. Vermutlich verhält es sich dabei ebenso.

Zugehörigkeit zur Terminreihe:

In beiden Fällen ist es so, dass beim Öffnen des verschobenen Termins der Dialog erscheint, ob man nur den einzelnen Termin oder die gesamte Reihe bearbeiten möchte. Für den Thunderbird gehört der verschobene Termin also noch zur Reihe. (Das habe ich nicht im ics kontrolliert.)

Wenn man nun die gesamte Reihe löscht, zeigt sich auch hier ein Unterschied.

Drag&Drop: Alle Termine werden der Reihe werden gelöscht.

Cut&Paste: Der verschobene bleibt stehen. Auch dann, wenn man den Thunderbird vor dem Löschen neu gestartet hat.

Zitat von Stylist

Beim Versuch, fehlende Angaben zu ergänzen wird man scheitern, man darf Eingaben zwar machen, aber nach TB-Neustart ist wieder alles verschwunden!

Das habe ich nicht reproduzieren können. Wenn ich in den verschobenen Termin nachträglich einen Ort eintrage, ist der auch nach einem Neustart da. Egal mit welcher Methode er zuvor verschoben wurde.

Zitat von Stylist

Deine Tests unterscheiden sich und sind möglicherweise auch nicht vergleichbar.

Klar unterscheiden sie sich. Mit Absicht. Schließlich stand oben u.a. die Frage im Raum, ob es einen Unterschied ausmacht, ob man lokale oder CalDAV-Kalender verwendet. Deshalb habe ich die Details meiner Umgebung auch extra angeführt und nicht nur plump geschrieben "Ich habe das selbe Problem."

Um ehrlich zu sein, Bug hin oder her, die angeführten Probleme betreffen mich in meinem Alltag nicht. Ich habe hier keine Not.

Meine Intention war, dir und den anderen weitere Informationen für einen Bug-Eintrag zu geben. Take it or leave it. Wenn schon ein Bug-Report zu viel verlangt ist, scheint es euch vielleicht auch nicht gar so zu pressieren.

Zitat von Stylist

Hast Du persönlich keine Probleme mit dem aktuellen Stand des Thunderbirds?

Nein, in meinen produktiven Installationen gibt es keine Probleme, die mich im Alltag stören würden.

Wie bereits geschrieben kannst du entweder die hier gegebenen Informationen (einschließlich den für die Eingrenzungen wichtigen Informationen von Susi to visit ), zusammen mit ggf. ein paar Experimenten, in präzise Fehlerberichte gießen und so dazu beitragen dass das Problem behoben wird – oder es lassen, und hoffen, dass sich schon irgendwann irgendjemand kümmern wird. Beides valide Standpunkte, aber hier weiterzudiskutieren wird das Problem nicht schneller lösen.