Hallo,
Es wäre schön, das Verhalten zu haben, das in #231 entfernt wurde.
Insbesondere die Möglichkeit, einen iCal-Client auf events.ics oder Äquivalentes zu verweisen, um alle Ereignisse auf der Website zu erhalten.
Zusätzlich fehlen die Felder DESCRIPTION, URL und ORGANIZER im Ersatz von download-calendar.js. Die ersten beiden sind für mich wichtiger.
Es wäre noch schöner, #169 zu integrieren, um “pro Thema” Ereignisexporte hinzuzufügen, aber das ist extra.
Ich würde mich auch sehr freuen, wenn ich Kalenderereignisse abonnieren könnte.
Als Spiegelung von /upcoming-events würde ich mir /upcoming-events.ics wünschen.
Aber ja, eine Möglichkeit, es für eine einzelne Kategorie (oder sogar ein einzelnes Tag?) zu erhalten, wäre wahrscheinlich auch eine großartige Ergänzung.
Vielleicht /upcoming-events.ics?category=12, um nach Kategorie-ID zu filtern?
+1 für vollständige ICS-Feeds, gefiltert nach Thema.
Ich weiß, dass dies aufgrund von Datenschutz schwierig ist. Der übliche Weg ist, dass ein zufälliger Hash-Feed generiert wird, der einen Feed pro Benutzer darstellt.
Ähm, was … es ist zumindest eine öffentliche URL mit welchem Kalender auch immer wir verwenden …
Ich möchte meine Unterstützung für diese Funktion ebenfalls bekunden. Ich habe bereits zu diesem Thema abgestimmt.
Die Wiedereinführung eines vollständigen oder benutzerspezifischen ICS-Exports wäre für den Workflow unserer Community äußerst wertvoll. Gibt es ein Update zur erneuten Prüfung dessen, was in PR #231 entfernt wurde?
Wenn es Datenschutz- oder Implementierungsbedenken gibt, könnte vielleicht ein privater, benutzerspezifischer ICS-Feed als Lösung in Betracht gezogen werden.
Vielen Dank für Ihre Berücksichtigung!
Ich glaube nicht, dass es Bedenken hinsichtlich des Datenschutzes gibt, da der .json-Endpunkt sowieso schon vorhanden ist, dies ist nur eine andere Art der Formatierung.
@cvx / @j.jaffeux Gedanken zur Rückkehr von .ics zur Event-Index-Route (entfernt in: DEV: Remove old ics code by CvX · Pull Request #231 · discourse/discourse-calendar · GitHub)? Scheint mir ein einfacher Gewinn zu sein.
Wir machen bereits:
DiscoursePostEvent::EventFinder.search(current_user, filtered_events_params)
Und können ein MAX_RESULTS (sortiert nach dem neuesten) haben, um sicherzustellen, dass dies und die .json nicht zu groß werden.
Ich habe die Möglichkeit für den ICS-Export über GET /discourse-post-event/events.ics wieder hinzugefügt (gemäß DEV: add ical format response for discourse-post-events index route by tyb-talks · Pull Request #35143 · discourse/discourse · GitHub). Beachten Sie, dass dieser Endpunkt eine harte Grenze von 200 Ereignissen hat. Wenn Ihre Website mehr als diese Anzahl von Ereignissen hat und Sie einen vollständigen Export durchführen möchten, können Sie dies durch die Verwendung der Abfrageparameter before und after tun, die Zeichenfolgen für Datumsangaben akzeptieren. Wir werden in Kürze die vollständige Liste der akzeptablen Parameter für diesen Endpunkt zu den API-Dokumenten hinzufügen.
Vielen Dank für das Mergen von PR #35143 — es ist großartig, den .ics-Export offiziell wieder zu sehen.
Eine Sache, die ich überprüfen wollte: Gibt es eine Möglichkeit (oder einen zukünftigen Plan), diesen Feed mit einem Benutzertoken oder API-Schlüssel zu authentifizieren, ähnlich wie Discourse private RSS/Atom-Feeds (/topics/feed.rss?token=…) behandelt?
Derzeit scheint /discourse-post-event/events.ics nur für öffentliche Veranstaltungen zu funktionieren, was bedeutet, dass Outlook / Google Kalender keine privaten Kategorien abonnieren können.
Selbst ein leichtgewichtiger tokenbasierter Ansatz (pro Benutzer oder pro Website, schreibgeschützt) würde es ermöglichen, private Veranstaltungen sicher in Kalenderclients anzuzeigen, ohne den Feed über ein externes Skript weiterleiten zu müssen.
Ist das etwas, das hinzugefügt werden könnte, oder ist es bereits durch einen vorhandenen Parameter möglich, den ich übersehen haben könnte?
Dies fühlt sich wie eine separate Funktionsanfrage an. Ich denke, es ist technisch mit einem API-Schlüssel machbar, daher ist die Frage, wie man dies einfach umsetzen könnte.
Ich werde dies schließen und Sie bitten, einen neuen Punkt dazu zu eröffnen.