Wir haben den neuen Reiter Kalender in den Benutzereinstellungen hinzugefügt, mit dem Sie Discourse-Feeds in externen Kalenderanwendungen wie Google Kalender, Apple Kalender und Microsoft Outlook abonnieren können.
Navigieren Sie zu Ihrem Reiter Einstellungen → Kalender und klicken Sie auf Abonnement-URLs generieren. Sie erhalten Ein-Klick-Abonnement-Schaltflächen für:
Google Kalender — öffnet Google Kalender mit dem vorausgefüllten Feed
Microsoft Outlook — öffnet den Dialog für Web-Abonnements von Outlook
Apple Kalender — löst die native Kalender-App über webcal:// aus
URL kopieren — für jede andere Kalenderanwendung, die ICS-Feeds unterstützt
Verfügbare Feeds
Immer verfügbar:
Lesezeichen-Erinnerungen — Ihre Lesezeichen mit Erinnerungsdaten
Meine Veranstaltungen — Veranstaltungen, an denen Sie teilnehmen oder an denen Sie interessiert sind
Für Plugin-Entwickler
Plugins können zusätzliche ICS-Feeds über die neue API register_calendar_subscription_feed registrieren. Auf diese Weise registrierte Feeds erscheinen automatisch im Reiter Kalender-Einstellungen, wenn das Plugin aktiviert ist.
Sicherheit
Abonnement-URLs verwenden eingeschränkte Benutzer-API-Schlüssel, die auf Lesezugriff im ICS-Format beschränkt sind. Schlüssel sind ratenbegrenzt, und URLs werden nur einmal bei der Generierung angezeigt – Benutzer können sie jederzeit neu generieren, was die alten URLs widerruft.
Vielen Dank @Falco, aber wie entfernt man die Unternehmensoptionen? Ich finde es beleidigend für meine Community, Werbung für proprietäre Dienste sehen zu müssen.
Vielen Dank für diese Implementierung – das wird die Nutzbarkeit des Kalender-/Ereignis-Plugins für viele Communities erhöhen!
Ich habe das gleiche Bedenken wie @hellekin: Innerhalb von Discourse befinden wir uns in einer Open-Source-Umgebung. In unserer Community nutzt niemand Google Kalender oder Microsoft. Wenn Benutzer einen Link für diese proprietären Dienste benötigen, sollten sie selbst entscheiden, nicht die Anwendung. Daher würde ich es vorziehen, die Art des externen Kalenderdienstes bei der Erstellung der Abonnement-URLs auszuwählen (z. B. mit einigen Kontrollkästchen) und nicht später.
Wir haben mehrere Communities auf unserer Discourse-Instanz. Sie sind durch Gruppenberechtigungen getrennt, und einige Benutzer sind Mitglied von mehr als einer Community. Es wäre praktisch, die URL „Discourse Calendar - All Events“ so zu filtern, dass nur die Kalendereinträge einer bestimmten Community angezeigt werden. Beispiel-URL
Mit dieser Erweiterung wäre es möglich, die Discourse-Ereignisse einer bestimmten (!) Community auf deren eigener Website zu teilen, z. B. mit dem WordPress-Plugin „ICS calendar“.
Ein weiterer kleiner Verbesserungsvorschlag: Wenn Sie die Discourse-Ereignisse bei zwei verschiedenen Clients abonnieren möchten (z. B. Thunderbird auf zwei Geräten), müssen Sie die URL zweimal kopieren. Die URL wird jedoch derzeit nur einmal angezeigt. Wenn Sie einen zweiten Client hinzufügen, müssen Sie die URLs neu generieren und verlieren dabei die ersten.
[quote=“Falco, post:7, topic:398902”]Du musst nur einmal kopieren und dann in die beiden gewünschten Clients einfügen.
Und falls du einen Client vergisst, kannst du ihn mit einem Klick neu generieren.
[/quote]
Ich verstehe, aber mein Punkt ist die notwendige Neuerstellung, nachdem die URLs zuerst angezeigt werden.
Wenn ich den Kalender-Link auf zwei verschiedenen Geräten verwende, sind diese wahrscheinlich nicht gleichzeitig für die Konfiguration verfügbar. Ich würde von dem ersten Gerät auf mein Discourse-Profil zugreifen und später erneut von dem zweiten Gerät. Es wäre besser, die alte URL erneut anzuzeigen und sie nur auf explizite Anfrage zu invalidieren.
Wenn ich Mitglied von zwei verschiedenen Communities (und deren Berechtigungsgruppen) bin, zeigt „https://discourse.example.com/discourse-post-event/events.ics“ die Ereignisse beider Communities an. Das ist soweit korrekt. Aber beide Communities haben möglicherweise ihre eigene Website. Wenn ich die Ereignisse von Discourse auf deren Websites teilen möchte, möchte ich nur die Ereignisse von „Community A“, aber nicht von „Community B“, sehen. Und umgekehrt.
Wenn du von den Kalenderservices anderer Anbieter sprichst, gilt dasselbe Prinzip: 1 bis 2 Mal pro Tag. Damals habe ich keine Lösung gefunden, um die Anzahl der Synchronisierungen zu erhöhen. Später habe ich mir gedacht, dass das angesichts der weltweiten Menge an zu synchronisierenden Kalendern eigentlich völlig normal ist Ich denke, er limitiert das, um ihre Server nicht zu überlasten!
Hintergrund: Unsere Discourse-Instanz wird von mehreren Benutzergruppen/Communities genutzt, die jeweils eigene Berechtigungsgruppen haben. Für jede dieser Gruppen gibt es eine Hauptkategorie. Diese Kategorie ist öffentlich sichtbar, und der Inhalt wird in das Fediverse (Discourse ActivityPub) federiert. Zudem wird ein öffentlicher Kalender angezeigt. Beispiel (https://forum.netzwissen.de/c/meshcore-str/84):
Der Kalender zeigt Veranstaltungen aus Beiträgen in der Hauptkategorie sowie aus Unterkategorien an. Veranstaltungsbeiträge in den Unterkategorien (die nur für „angemeldete“ Nutzer mit der Berechtigungsgruppe der Community sichtbar sind) werden im Hauptkalender für anonyme Nutzer (nicht angemeldet) nicht angezeigt. Perfekt – das ist das erwartete Verhalten!
Ich sehe zwei Anforderungen, die den ICS-Kalenderlink „funktionsfertig“ machen würden. Wir nutzen den neuen ICS-Kalenderlink, um in Discourse erstellte Veranstaltungen auf den öffentlichen Websites der Communities (CMS: WordPress) zu teilen.
Im ICS-Datei angezeigte Veranstaltungen sollten nach Community/Berechtigungsgruppe „filterbar“ sein. Vorgeschlagene Syntax:
Die ICS-Datei sollte nur Veranstaltungen mit dem Status „public“ anzeigen. Der Status „private“ oder „standalone“ sollte im ICS-Datei im Allgemeinen nicht veröffentlicht werden. Hinweis: Ich habe noch nicht getestet, ob dies bereits implementiert ist …
Leider wird beim Generieren der URLs für meinen Benutzer nur das Lesezeichen-Abonnement erstellt, obwohl das Kalender-Plugin aktiviert ist (und wir es regelmäßig nutzen). Hat jemand eine Idee, warum das so sein könnte?
Ich stimme auch @Thomas_Rother zu, dass Abonnement-URLs bis zu ihrer Widerrufung oder Neugenerierung angezeigt werden sollten. Geräte und Apps ändern sich im Laufe der Zeit, und alle Geräte neu abonnieren zu müssen, nur weil man eines hinzufügen möchte, ist mühsam und scheint unnötig. Vielleicht könnte dies eine Plugin-Konfigurationsoption sein, je nach Sensibilität der Ereignisdaten.
Könnte das ein Problem bei Installationen sein, die zuvor das separate Plugin verwendet haben? Ich habe auch versucht, das Plugin zu deaktivieren und erneut zu aktivieren, aber das hat das Problem nicht behoben.
Ich bin hierher gekommen, weil ich genau nach dieser Funktion gesucht habe, und ich freue mich sehr, dass sie umgesetzt wurde!
Ich teile das Feedback von @hellekin und @Thomas_Rother bezüglich der Unternehmenslinks. Wenn diese optional gemacht werden könnten, wäre das großartig. Viele Menschen nutzen Discourse, weil sie an digitale Souveränität glauben, sodass das Erscheinen dieser Logos nicht angemessen ist.
Noch wichtiger ist die Auffindbarkeit der Funktion. Sie ist in den Benutzerpräferenzen versteckt, wäre aber direkt in der Kalender-UI-Navigation sehr willkommen. Auf „Anstehende Veranstaltungen
Ich denke, er limitiert das, um ihre Server nicht zu überlasten!
