Nome do arquivo ICS indefinido

:information_source: Visão Geral

Ao clicar em “Adicionar ao calendário” na janela modal de visualização do evento (aquela que aparece após clicar na data do evento):

o arquivo .ics baixado é nomeado undefined.ics e o título do evento dentro do arquivo do calendário também é definido como SUMMARY:undefined. No entanto, o download do calendário através da opção “Adicionar ao calendário” no menu de 3 pontos do evento funciona como esperado, usando o título do evento tanto para o nome do arquivo quanto para o resumo do calendário.

:walking_woman: Passos para reproduzir

  1. Crie ou abra um tópico com um evento
  2. Clique na data do evento mostrada na postagem para expandir a janela modal de visualização
  3. Na janela modal, clique em Adicionar ao calendário
  4. Salve o arquivo .ics gerado.
  5. Opcionalmente, compare clicando no menu de 3 pontos do evento e usando Adicionar ao calendário a partir daí

:white_check_mark: Resultados esperados

  • O arquivo .ics baixado deve ser nomeado de acordo com o título do evento
  • O conteúdo do arquivo do calendário deve ter um SUMMARY: correto com o título do evento

:x: Resultados observados

  • O arquivo baixado é nomeado undefined.ics
  • O título do evento no arquivo do calendário é SUMMARY:undefined
  • (Ao baixar do menu de 3 pontos, tanto o nome do arquivo quanto o resumo estão corretos.)

:books: Contexto adicional

  • Exemplo de conteúdo ICS malformado:
    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:-//Discourse//EN
    BEGIN:VEVENT
    UID:1762794000000_1762801200000
    DTSTAMP:20251105T173754Z
    DTSTART:20251110T170000Z
    DTEND:20251110T190000Z
    SUMMARY:undefined
    END:VEVENT
    END:VCALENDAR
    

Testado no Meta e em vários outros sites do Discourse, mesmo resultado.

3 curtidas

Este é um caso complicado, Dax, que é um efeito colateral do nosso pipeline.

Geramos o bbcode para as datas aqui:

E processamos aqui:

Portanto, no contexto do trecho de HTML processado, o “download ics” não tem conhecimento da postagem real em que está (ou do evento).

Também temos um pipeline diferente para geração de ics em:

Portanto, precisamos decidir, de uma perspectiva de engenharia, se:

  1. Ensinamos o “date cooking” a redirecionar a geração de ics para o Discourse Calendar.

OU

  1. Fornecemos contexto suficiente para o Discourse Local Dates, para que ele possa gerar o ics de forma independente e manter o código fragmentado.

Não tenho certeza do que é a coisa certa a fazer aqui, mas priorizei para que a equipe possa triar e resolver.

5 curtidas

Olá a ambos, para adicionar algum contexto, se você clicar nos três pontos em um evento, há uma opção Adicionar ao Calendário e isso funciona. Não sei se isso pode ajudar você a investigar isso, mas parece que já foi resolvido em outro lugar no código.

6 curtidas

Há MUITO aqui:

É sexta-feira (pelo menos em algum lugar ;p ), então vou esperar até segunda-feira para mesclar.

Esta alteração é incrivelmente extensa e deve nos dar um suporte ICS significativamente melhor.

  • Unifica o pipeline para geração de ICS - usamos apenas um mecanismo para adicionar ao calendário e clicar em datas
  • Corrige muitos pequenos detalhes de nuance no formato ics
    • Passamos RRULE para que, se você pegar um evento recorrente
    • Quebras de linha CRLF adequadas e adesão geral ao formato ICS
    • Suporte a fuso horário, para que, quando você pegar um ICS para um evento, ele sinalize o fuso horário correto em vez de ser um evento UTC - isso significa que a recorrência funcionará.
  • Expande o formato de datas locais para suportar um ics opcionalmente codificado

Uma pergunta em aberto que tenho é sim, rrule ou não, rrule.

Se você clicar aqui:

Pretendemos adicionar o evento recorrente? Ou apenas uma única instância do evento?

Da mesma forma, e quanto a aqui:

@lindsey Estou indeciso aqui, posso ver os argumentos para ambos os lados.

  1. Cliquei em um evento recorrente e queria adicionar a recorrência ao meu calendário

OU

  1. Cliquei em uma INSTÂNCIA de uma recorrência e só quero adicioná-la.

Implementei (1) porque tendo a sentir que é mais correto, mas estou aberto a mudar para (2) se você preferir.

7 curtidas

Uma postagem foi mesclada em um tópico existente: Página de eventos futuros quebrada após atualização recente

Consigo entender o argumento em qualquer direção, mas também prefiro 1. Acho que é mais correto e mais fácil de “corrigir” se não for o que o usuário queria, porque a maioria dos softwares de calendário facilitam a exclusão de eventos extras com uma única ação (como o Google Calendar):

Portanto, o incômodo de:

  • Não queria confirmar presença em todos os eventos, então preciso remover os extras

É muito menor do que o incômodo de:

  • Eu queria confirmar presença em todos os eventos, então preciso voltar aqui toda semana e garantir que continuo adicionando-os ao meu calendário
5 curtidas

Legal, eu mantive o RSVP para todos.

Foi mesclado hoje :confetti_ball:

5 curtidas

Este tópico foi fechado automaticamente após 4 dias. Novas respostas não são mais permitidas.