Undefinierter ICS-Dateiname

:information_source: Übersicht

Wenn Sie im Vorschaufenster des Ereignisses (das nach dem Klicken auf das Datum des Ereignisses angezeigt wird) auf „Zum Kalender hinzufügen“ klicken:

wird die heruntergeladene .ics-Datei als undefined.ics benannt und der Ereignistitel in der Kalenderdatei wird ebenfalls auf SUMMARY:undefined gesetzt. Das Herunterladen des Kalenders über die Option „Zum Kalender hinzufügen“ aus dem 3-Punkte-Menü des Ereignisses funktioniert jedoch wie erwartet, wobei der Titel des Ereignisses sowohl für den Dateinamen als auch für die Kalendersummary verwendet wird.

:walking_woman: Schritte zur Reproduktion

  1. Erstellen oder öffnen Sie ein Thema mit einem Ereignis.
  2. Klicken Sie auf das Datum des Ereignisses, das im Beitrag angezeigt wird, um das Vorschaufenster zu erweitern.
  3. Klicken Sie im Modal auf Zum Kalender hinzufügen.
  4. Speichern Sie die generierte .ics-Datei.
  5. Vergleichen Sie optional, indem Sie auf das 3-Punkte-Menü des Ereignisses klicken und dort „Zum Kalender hinzufügen“ verwenden.

:white_check_mark: Erwartete Ergebnisse

  • Die heruntergeladene .ics-Datei sollte nach dem Titel des Ereignisses benannt sein.
  • Der Inhalt der Kalenderdatei sollte eine korrekte SUMMARY: mit dem Titel des Ereignisses enthalten.

:x: Beobachtete Ergebnisse

  • Die heruntergeladene Datei heißt undefined.ics.
  • Der Titel des Ereignisses in der Kalenderdatei lautet SUMMARY:undefined.
  • (Beim Herunterladen aus dem 3-Punkte-Menü sind sowohl der Dateiname als auch die Zusammenfassung korrekt.)

:books: Zusätzlicher Kontext

  • Beispiel für fehlerhaften ICS-Inhalt:
    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:-//Discourse//EN
    BEGIN:VEVENT
    UID:1762794000000_1762801200000
    DTSTAMP:20251105T173754Z
    DTSTART:20251110T170000Z
    DTEND:20251110T190000Z
    SUMMARY:undefined
    END:VEVENT
    END:VCALENDAR
    

Auf Meta und mehreren anderen Discourse-Seiten getestet, gleiches Ergebnis.

3 „Gefällt mir“

Das ist eine knifflige Sache, Dax, die eine Nebenwirkung unserer Pipeline ist.

Wir generieren hier den BBCode für die Daten:

Und kochen ihn hier:

Im Kontext des gekochten HTML-Chunks ist der “ICS-Download” nicht über den eigentlichen Beitrag (oder das Ereignis) informiert, auf dem er sich befindet.

Wir haben auch eine andere Pipeline für die ICS-Generierung unter:

Wir müssen uns also aus technischer Sicht entscheiden, ob:

  1. Wir das “Date Cooking” so lehren, dass es die ICS-Generierung an Discourse Calendar weiterleitet.

ODER

  1. Wir Discourse Local Dates genügend Kontext geben, damit es den ICS unabhängig generieren kann und der Code fragmentiert bleibt.

Ich bin mir nicht sicher, was hier das Richtige ist, aber ich habe es priorisiert, damit das Team es sichten und klären kann.

5 „Gefällt mir“

Hallo ihr beiden, um etwas Kontext zu geben: Wenn ihr auf die drei Punkte bei einem Ereignis klickt, gibt es die Option Zum Kalender hinzufügen und diese funktioniert tatsächlich. Ich weiß nicht, ob euch das bei der Untersuchung helfen kann, aber es scheint, als wäre das Problem bereits anderswo im Code gelöst worden.

6 „Gefällt mir“

Hier gibt es VIEL zu tun:

Es ist Freitag (zumindest irgendwo ;p ), also warte ich bis Montag mit dem Zusammenführen.

Diese Änderung ist unglaublich umfangreich und sollte uns eine deutlich bessere ICS-Unterstützung bieten.

  • Vereinheitlicht die Pipeline für die ICS-Generierung – wir verwenden nur einen Mechanismus sowohl für das Hinzufügen zum Kalender als auch für das Klicken auf Daten
  • Korrigiert viele kleine Nuancen im ICS-Format
    • Wir übergeben RRULE, wenn Sie ein wiederkehrendes Ereignis abrufen
    • Korrekte CRLF-Zeilenumbrüche und allgemeine Einhaltung des ICS-Formats
    • Zeitzonenunterstützung, sodass beim Abrufen eines ICS für ein Ereignis die richtige Zeitzone signalisiert wird, anstatt ein UTC-Ereignis zu sein – das bedeutet, dass die Wiederholung funktioniert.
  • Erweitert das lokale Datumsformat, um ein optional kodiertes ICS zu unterstützen.

Eine offene Frage, die ich habe, ist ja, rrule oder nein, rrule.

Wenn Sie hier klicken:

Wollen wir das wiederkehrende Ereignis hinzufügen? Oder nur eine einzelne Instanz des Ereignisses?

Ebenso, was ist hier:

@lindsey Ich bin unschlüssig, ich kann beide Argumente nachvollziehen.

  1. Ich habe auf ein wiederkehrendes Ereignis geklickt und wollte die Wiederholung zu meinem Kalender hinzufügen.

ODER

  1. Ich habe auf eine INSTANZ einer Wiederholung geklickt und möchte nur diese hinzufügen.

Ich habe (1) implementiert, da ich tendenziell der Meinung bin, dass es korrekter ist, aber ich bin offen dafür, es zu (2) zu ändern, wenn Sie es bevorzugen.

7 „Gefällt mir“

Ein Beitrag wurde in ein bestehendes Thema zusammengeführt: Upcoming events page broken after recent update

Ich kann die Argumentation in beide Richtungen nachvollziehen, aber ich bevorzuge ebenfalls 1. Ich denke, es ist sowohl korrekter als auch einfacher zu “reparieren”, wenn es nicht das war, was der Benutzer wollte, da die meisten Kalendersoftware es ziemlich einfach macht, zusätzliche Ereignisse mit einer einzigen Aktion zu löschen (wie z. B. Google Kalender):

Der Aufwand, um:

  • Ich wollte nicht auf alle Ereignisse antworten, also muss ich die zusätzlichen entfernen

Ist viel geringer als der Aufwand, um:

  • Ich wollte auf alle Ereignisse antworten, also muss ich jede Woche hierher zurückkommen und sicherstellen, dass ich sie weiterhin zu meinem Kalender hinzufüge
5 „Gefällt mir“

Cool, ich habe die RSVP auf alle beibehalten.

Es wurde heute zusammengeführt :confetti_ball:

5 „Gefällt mir“

Dieses Thema wurde nach 4 Tagen automatisch geschlossen. Neue Antworten sind nicht mehr möglich.