Olá,
Seria bom ter o comportamento que foi removido em #231.
Especificamente, poder apontar um cliente ical para events.ics ou equivalente para obter todos os eventos no site.
Além disso, os campos DESCRIPTION, URL e ORGANIZER estão faltando na substituição de download-calendar.js. Os dois primeiros são mais importantes para mim.
Seria ainda melhor incorporar #169 para adicionar exportações de eventos “por tópico”, mas isso é extra.
Eu também ficaria muito feliz se pudesse me inscrever em eventos do meu calendário.
Espelhando /upcoming-events, eu adoraria ver um /upcoming-events.ics.
Mas sim, ter uma maneira de obtê-lo para uma única categoria (ou até mesmo uma única tag?) provavelmente seria uma ótima adição também.
Talvez /upcoming-events.ics?category=12 para filtrar por ID de categoria?
+1 no feed completo de ICS e filtrado por tópico.
Sei que isso é difícil por causa da privacidade. O caminho usual é que um feed de hash aleatório representando um feed por usuário é gerado.
umm o quê … é um URL público pelo menos com qualquer calendário que usemos …
Eu também quero expressar meu apoio a este recurso. Já votei neste tópico.
Trazer de volta uma exportação ICS completa do site ou por usuário seria extremamente valioso para o fluxo de trabalho de nossa comunidade. Há alguma atualização sobre a reconsideração do que foi removido em PR #231?
Se houver preocupações de privacidade ou implementação, talvez um feed ICS privado e por usuário possa ser considerado como uma solução.
Obrigado por considerar isso!
Não acho que haja preocupações com privacidade, pois o endpoint .json já existe de qualquer forma, este é apenas um tipo diferente de formatação.
@cvx / @j.jaffeux, o que acham de trazer de volta o .ics para a rota de índice de eventos (removido em: DEV: Remove old ics code by CvX · Pull Request #231 · discourse/discourse-calendar · GitHub)? Parece uma vitória fácil para mim.
Nós já fazemos:
DiscoursePostEvent::EventFinder.search(current_user, filtered_events_params)
E podemos ter um MAX_RESULTS (ordenado pelo mais recente) para garantir que isso e o .json não fiquem muito grandes.
Adicionei de volta a capacidade de exportação de ics via GET /discourse-post-event/events.ics (a partir de DEV: add ical format response for discourse-post-events index route by tyb-talks · Pull Request #35143 · discourse/discourse · GitHub). Note que este endpoint tem um limite rígido de 200 eventos. Se o seu site tiver mais eventos do que isso e você quiser fazer uma exportação completa, poderá iterar usando os parâmetros de consulta before e after, que aceitam strings de data. Adicionaremos a lista completa de parâmetros aceitáveis para este endpoint à documentação da API em devido tempo.
Obrigado por mesclar PR #35143 — ótimo ver a exportação .ics oficialmente de volta.
Uma coisa que eu queria verificar: existe alguma possibilidade (ou plano futuro) de autenticar este feed com um token de usuário ou chave de API, semelhante a como o Discourse lida com feeds RSS/Atom privados (/topics/feed.rss?token=…)?
No momento, /discourse-post-event/events.ics parece funcionar apenas para eventos públicos, o que significa que Outlook / Google Calendar não podem assinar categorias privadas.
Mesmo uma abordagem leve baseada em token (por usuário ou por site, somente leitura) tornaria possível expor eventos privados de forma segura em clientes de calendário sem ter que fazer proxy do feed através de um script externo.
É algo que poderia ser adicionado, ou já é possível através de um parâmetro existente que eu possa ter perdido?
Isso parece uma solicitação de recurso separada. Acho que é tecnicamente factível com uma chave de API, então acho que a questão é como você facilitaria isso.
Vou fechar isso e deixar você abrir um novo item sobre isso.