Ciao,
Sarebbe bello avere il comportamento rimosso in #231.
Nello specifico, poter puntare un client ical verso events.ics o equivalente per ottenere tutti gli eventi sul sito.
Inoltre, i campi DESCRIPTION, URL e ORGANIZER mancano dalla sostituzione di download-calendar.js. I primi due sono più importanti per me.
Sarebbe ancora più bello integrare #169 per aggiungere esportazioni di eventi “per argomento”, ma questo è un extra.
Sarei anche molto felice se potessi sottoscrivere eventi dal mio calendario.
Rispecchiando /upcoming-events mi piacerebbe vedere un /upcoming-events.ics.
Ma sì, avere un modo per ottenerlo per una singola categoria (o anche un singolo tag?) sarebbe probabilmente una grande aggiunta.
Forse /upcoming-events.ics?category=12 per filtrare per ID categoria?
+1 sul feed ics completo e filtrato per argomento.
So che è difficile a causa della privacy. Il percorso usuale è che viene generato un feed hash casuale che rappresenta un feed per utente.
umm cosa … è un URL pubblico almeno con qualsiasi calendario utilizziamo …
Voglio solo aggiungere il mio supporto anche a questa funzionalità. Ho già votato su questo argomento.
Riportare un’esportazione ICS completa del sito o per utente sarebbe estremamente prezioso per il flusso di lavoro della nostra community. Ci sono aggiornamenti sulla riconsiderazione di quanto è stato rimosso in PR #231?
Se ci sono preoccupazioni sulla privacy o sull’implementazione, forse si potrebbe considerare un feed ICS privato per utente come soluzione.
Grazie per aver preso in considerazione questo aspetto!
Non credo ci siano preoccupazioni sulla privacy, poiché l’endpoint .json è già disponibile, si tratta solo di un diverso tipo di formattazione.
@cvx / @j.jaffeux pensieri sul ripristino di .ics alla route dell’indice degli eventi (rimosso in: DEV: Remove old ics code by CvX · Pull Request #231 · discourse/discourse-calendar · GitHub)? Mi sembra una vittoria facile.
Facciamo già:
DiscoursePostEvent::EventFinder.search(current_user, filtered_events_params)
E possiamo avere un MAX_RESULTS (ordinato per più recente) per garantire che questo e il .json non diventino troppo grandi.
Ho ripristinato la funzionalità di esportazione ICS tramite GET /discourse-post-event/events.ics (come da DEV: add ical format response for discourse-post-events index route by tyb-talks · Pull Request #35143 · discourse/discourse · GitHub). Si noti che questo endpoint ha un limite massimo di 200 eventi. Se il tuo sito ha più eventi di questo numero e desideri un’esportazione completa, puoi iterare utilizzando i parametri di query before e after che accettano stringhe di date. Aggiungeremo l’elenco completo dei parametri accettabili per questo endpoint alla documentazione API a tempo debito.
Grazie per aver unito PR #35143 — è bello vedere l’esportazione .ics ufficialmente di nuovo disponibile.
Una cosa che volevo verificare: c’è qualche possibilità (o piano futuro) di autenticare questo feed con un token utente o una chiave API, simile a come Discourse gestisce i feed RSS/Atom privati (/topics/feed.rss?token=…)?
Al momento /discourse-post-event/events.ics sembra funzionare solo per eventi pubblici, il che significa che Outlook / Google Calendar non possono iscriversi a categorie private.
Anche un approccio leggero basato su token (per utente o per sito, in sola lettura) renderebbe possibile esporre in modo sicuro eventi privati nei client di calendario senza dover inoltrare il feed tramite uno script esterno.
È qualcosa che potrebbe essere aggiunto, o è già possibile tramite un parametro esistente che potrei essermi perso?
Questa sembra una richiesta di funzionalità separata. Penso che sia tecnicamente fattibile con una chiave API, quindi immagino che la domanda sia come potresti implementarla facilmente.
Chiuderò questo ticket e ti permetterò di aprirne uno nuovo a riguardo.