Adicionamos uma nova aba Calendário às preferências do usuário que permite assinar feeds do Discourse em aplicativos de calendário externos como Google Agenda, Apple Calendar e Microsoft Outlook.
Meus Eventos — eventos que você vai participar ou tem interesse
Para desenvolvedores de plugins
Plugins podem registrar feeds ICS adicionais usando a nova API register_calendar_subscription_feed. Feeds registrados dessa forma aparecem automaticamente na aba de preferências do Calendário quando o plugin está ativado.
Segurança
Os URLs de assinatura usam chaves de API de usuário com escopo restritas ao acesso somente leitura no formato ICS. As chaves são limitadas por taxa, e os URLs são exibidos apenas uma vez no momento da geração — os usuários podem regenerar a qualquer momento, o que revoga os URLs antigos.
Muito obrigado por esta implementação - isso aumentará a usabilidade do plugin de calendário/eventos para muitas comunidades!
Tenho a mesma objeção que @hellekin: dentro do Discourse, estamos em um ambiente de Código Aberto. Em nossa comunidade, ninguém usa o Google Calendar ou o Microsoft. Se os usuários precisarem de um link para esses serviços proprietários, eles devem decidir por si mesmos, não o aplicativo. Portanto, eu preferiria selecionar o tipo de serviço de calendário externo na etapa de criação dos URLs de assinatura (por exemplo, com algumas caixas de seleção), e não mais tarde.
Temos várias comunidades em nossa instância do Discourse. Elas são separadas por permissões de grupo e alguns usuários são membros de mais de uma comunidade. Seria conveniente filtrar a URL “Discourse Calendar - All Events” para que ela exiba apenas as entradas do calendário de uma comunidade específica. URL de exemplo
Com este aprimoramento, seria possível compartilhar os eventos do Discourse de uma comunidade específica (!) em seu próprio site, por exemplo, com o plugin do WordPress “ICS calendar”.
Outro pequeno aprimoramento proposto: se você quiser assinar os eventos do Discourse em dois clientes diferentes (por exemplo, Thunderbird em dois dispositivos), você precisa copiar o URL duas vezes. Mas atualmente o URL é exibido apenas uma vez. Se você adicionar um segundo cliente, terá que regenerar os URLs e, assim, perderá os primeiros.
[quote=“Falco, post:7, topic:398902”]Você precisa copiar apenas uma vez, depois colar nos dois clientes que você precisa.
E se você esquecer um cliente, pode regenerar com um clique.
[/quote]
Eu entendo, mas o meu ponto é a regeneração necessária depois que os URLs são mostrados primeiro.
Se eu usar o link do calendário em dois dispositivos diferentes, eles provavelmente não estarão disponíveis para configuração ao mesmo tempo. Eu acessaria meu perfil do Discourse a partir do primeiro dispositivo e depois novamente a partir do segundo dispositivo. Seria melhor mostrar o URL antigo novamente e invalidá-lo apenas por solicitação explícita.
Se eu for membro de duas comunidades diferentes (e seus grupos de permissão), o “https://discourse.example.com/discourse-post-event/events.ics“ mostra os eventos de ambas as comunidades. Isso está correto até agora. Mas ambas as comunidades podem ter seu próprio website. Se eu quiser compartilhar os eventos do Discourse em seus websites, eu só gostaria de ver os eventos da “comunidade A”, mas não da “comunidade B”. E vice-versa.
Se você está falando dos serviços de agenda de outros provedores, o princípio é o mesmo: 1 a 2 vezes por dia. Na época, não encontrei uma solução para aumentar a frequência de sincronização. Depois, percebi que faz todo sentido, considerando o número de agendas que precisam ser sincronizadas no mundo Acho que eles limitam para não saturar os servidores!
Contexto: nossa instância do Discourse é compartilhada entre vários grupos/comunidades de usuários, que possuem grupos de permissão separados. Temos uma categoria principal para cada um desses grupos. Essa categoria é publicamente visível e o conteúdo é federado no Fediverse (Discourse ActivityPub). Também exibe um calendário público. Exemplo (https://forum.netzwissen.de/c/meshcore-str/84):
O calendário exibe eventos de posts na categoria principal e também em subcategorias. Posts de eventos nas subcategorias (que são visíveis apenas para usuários “logados” com o grupo de permissão da comunidade) não aparecem no calendário principal para usuários anônimos (não logados). Perfeito — esse é o comportamento esperado!
Identifiquei dois requisitos que tornariam o link do calendário ICS “completo em funcionalidades”. Utilizamos o novo link do calendário ICS para compartilhar eventos criados no Discourse nos sites públicos das comunidades (CMS: WordPress).
Os eventos exibidos no arquivo ICS devem ser “filtráveis” por comunidade/grupo de permissão. Sintaxe proposta:
O arquivo ICS deve exibir apenas eventos com status “público”. Eventos com status “privado” ou “autônomo” geralmente não devem ser publicados no arquivo ICS. Observação: ainda não testei se isso já está implementado…
Infelizmente, mesmo com o plugin de Calendário ativado (e que temos usado regularmente), apenas a assinatura de Favoritos está sendo criada quando gero os URLs para o meu usuário. Alguma ideia do porquê isso possa estar acontecendo?
Também concordo com @Thomas_Rother de que os URLs de assinatura devem permanecer visíveis até serem revogados ou regenerados. Dispositivos e aplicativos mudam com o tempo, e ter que reassinar em todos os dispositivos apenas porque você quer adicionar mais um é trabalhoso e parece desnecessário. Talvez isso pudesse ser uma opção de configuração do plugin, dependendo da sensibilidade dos dados dos eventos.
Será que pode ser um problema com instalações que usavam o plugin separado antes? Também tentei desativar e reativar o plugin, mas isso não resolveu o problema.
Vim aqui procurando exatamente esse recurso, então estou muito feliz por ele ter sido implementado!
Compartilho o feedback de @hellekin e @Thomas_Rother sobre os links corporativos. Se esses links pudessem ser opcionais, seria ótimo. Muitas pessoas usam o Discourse porque acreditam na soberania digital, então ter esses logotipos aparecendo não é apropriado.
Mais importante ainda é a descoberta do recurso. Ele está escondido nas preferências do usuário, mas seria muito bem-vindo diretamente na navegação da interface do calendário. Clicar em “Próximos eventos” e depois ver um link para se inscrever seria ouro.
Acho que eles limitam para não saturar os servidores!
