Realmente precisamos criar um novo tópico para cada evento, em vez de um único tópico de evento controlar vários eventos visíveis no calendário.
No momento, a única solução viável é criar manualmente vários novos tópicos. Isso, claro, enche o feed “Mais Recentes” de forma muito irritante (o que precisa de alguma mitigação), além de exigir cuidado para não notificar em excesso. Acho que isso destaca alguns dos desafios em trazer essa funcionalidade à vida.
Ideia fofa, mas acho que não vai ser suficiente — cada evento de uma série realmente precisa de sua própria confirmação de presença, informações complementares e discussão.
O RSVP seria substituído pela enquete, de modo que todos os eventos no tópico seriam autônomos. Todos os eventos girariam em torno da mesma questão: a complexidade de definir um horário entre várias opções.
Não é realmente uma série nem algo que possa ser realizado no Outlook.
É o ingrediente especial que faz com que uma instituição, como a universidade em que estou, se afaste das séries defensivamente falsas do Outlook e migre para o Discourse.
Volto a falar sobre isso depois de usar a versão atualizada do plugin nos últimos meses; ele está funcionando muito bem agora que temos mais opções de recorrência – especialmente o dia X do mês e a capacidade de confirmar presença tanto no evento quanto na série.
No entanto, um problema fundamental permanece: arquivar o conteúdo do último evento.
O caso de uso é um evento recorrente que tem várias publicações/discussões associadas. Isso pode incluir arquivos anexados e imagens. O exemplo mais óbvio é uma reunião de trabalho regular.
No momento, essa bagunça resultante precisa ser organizada manualmente de uma forma ou de outra, pois o que a recorrência faz é simplesmente alterar a data do evento e limpar as confirmações de presença. As opções manuais são:
Desativar a recorrência antes/durante o Evento e publicar um novo Evento para o próximo mês
Mover as publicações relevantes para uma publicação de arquivo dedicada
Excluir automaticamente as publicações na publicação do evento (embora o timing disso seja estranho)
Esquecer toda a questão da recorrência para esses tipos de eventos e fazer tudo manualmente
Infelizmente, nenhuma dessas opções é ideal.
O que eu gostaria de ver em vez disso
Gostaria que a recorrência mantivesse o tópico atual do Evento intacto, mas, uma vez concluído, o plugin criaria um novo Tópico para o próximo Evento.
Isso manteria o fluxo agradável e garantiria automaticamente que um arquivo apropriado do evento passado seja retido – além de fornecer um Tópico “limpo” para o novo evento.
O preço a pagar (além da complexidade aumentada) seria que o evento ativo teria uma nova URL. Eu poderia ver isso potencialmente sendo um problema em alguns casos.
Olá, isso implica que você precisará esperar o evento atual da série de eventos recorrentes ser encerrado antes de poder se inscrever no próximo evento?
A maioria dos plugins de eventos em que trabalhei no Joomla cria a série de eventos diretamente, ao contrário da sua ideia aqui, que criaria tópicos/URLs individuais por evento, o que, na minha opinião, é o modelo correto.
Oferecer a opção de desativar a inscrição até x dias antes dos eventos recorrentes também seria prático.
Quanto à parte de arquivamento, os eventos não costumam residir em sua própria subcategoria ou serem suficientemente marcáveis para mantê-los juntos e ter uma ação automatizada sobre eles?
Sim, mas isso não é diferente da situação atual, em que você pode responder ao evento atual ou a toda a série.
Você quer dizer uma ação para clonar o evento e mover as respostas, ou algo semelhante? Talvez os Workflows possam fazer isso; eu estava pensando em investigar isso.
Na minha experiência com eventos, responder a toda a série é menos usado do que poder se inscrever em um evento específico mais adiante na série; no entanto, ambas as opções são importantes.
Sim, no entanto, não vejo em minha instalação nenhum workflow que faça isso.
Talvez isso seja, em si, outro pedido de funcionalidade e interessante além do escopo do tópico de eventos, e eu poderia/deveria criar outro tópico para isso.
Precisaríamos de uma ação de arquivamento automático acionada por certas condições; neste caso, seria quando a “data do evento ou a data de término, se houver” estiver no passado ou o tópico estiver fechado há x dias, com talvez um atraso selecionável antes de a ação ocorrer, para que o tópico do evento ainda possa permanecer visível para as pessoas comentarem após o evento por alguns dias.
Um gatilho Event ended (Evento encerrado) para Workflows (Fluxos de trabalho) foi agora mesclado:
Além disso, os Workflows já possuem uma ação Topic (Tópico) que pode Get (Obter) um tópico existente e Create (Criar) um novo, e há um nó Wait (Aguardar). Portanto, uma boa parte da rolagem proposta pode já ser composta como um fluxo de trabalho, em vez de exigir um recurso de arquivamento dedicado e específico para eventos.
Algo ao longo das linhas de:
Event ended → Wait → Topic / Get → Topic / Create
potencialmente poderia criar um tópico sucessor usando os dados de título/corpo/categoria do tópico antigo, enquanto mantém o tópico concluído intacto como arquivo.
O que ainda precisaria ser verificado é exatamente quais partes do tópico antigo devem ser copiadas automaticamente — por exemplo, tags, uploads, estado de recorrência do evento e se as respostas devem ser movidas ou simplesmente deixadas para trás.
Também tenho um PR aberto introduzindo uma ação Event (Evento) para os Workflows:
O PR base adiciona Close event (Fechar evento) e Open event (Abrir evento), e tenho um follow-up empilhado adicionando Set attendance (Definir presença):
A ação é estruturada de modo que operações específicas de evento adicionais possam ser adicionadas como follow-ups separados onde fizer sentido.
Bom trabalho, obrigado. As condições de encerramento podem ser úteis, mas talvez não sejam totalmente aplicáveis à situação original.
Uma categoria de eventos pode crescer bastante, especialmente com eventos recorrentes, e faria sentido oferecer uma forma de arquivar/mover automaticamente qualquer tópico de evento fechado há x dias para uma categoria de tópicos passados ou arquivá-los.
Mas essa questão de arquivamento depende da decisão de fazer com que os eventos recorrentes se tornem tópicos individuais vinculados ao tópico principal do evento.
Abri um PR implementando isso como um modo de Evento recorrente opcional (opt-in):
Ele adiciona uma configuração de site discourse_post_event_recurring_topic_mode com duas opções:
reuse_topic — o comportamento existente e o padrão
create_next_topic — preserva o tópico da ocorrência concluída e cria um novo tópico para a próxima ocorrência
Com create_next_topic, quando uma ocorrência termina, o tópico concluído é mantido com seu Evento fixado naquela ocorrência concluída e a recorrência removida. Um tópico sucessor é então criado para a próxima recorrência, preservando o título/corpo originais, a categoria, as tags e o autor, enquanto avança as datas do Evento.
Os testes automatizados também cobrem a semântica de transferência de RSVPs: a presença recorrente going é transferida para o sucessor, enquanto a presença de uso único permanece com a ocorrência concluída.
A transferência também é transacional, então, se a criação do sucessor falhar, a ocorrência permanece pendente e pode ser tentada novamente, em vez de ficar parcialmente concluída.
Isso implementa especificamente o modelo “criar o próximo tópico quando a ocorrência atual termina”. Ele ainda não gera tópicos individuais para todas as ocorrências futuras antecipadamente, que é o modelo alternativo mencionado acima por @opcourdis.
O comportamento existente permanece como padrão, portanto, isso é opcional (opt-in) para sites que desejam que o tópico do Evento concluído funcione como um arquivo.
Obrigado, esse modelo já funciona muito bem para organizadores, que agora podem ter a certeza de que não precisarão recriar um evento a cada vez, e também oferece a segurança de que as pessoas não se inscreverão com antecedência, pois os organizadores sempre podem cancelar um evento por certos motivos.
O modelo de criação antecipada que sugeri também funciona para muitos casos e complementaria seu modelo de sucessão de eventos.
1° As pessoas que se inscrevem no novo evento ainda ficam sabendo que o tópico/evento faz parte de uma série de eventos recorrentes, assim como o evento/tópico original?
2° O seu convite automático aos convidados originais para o evento é uma opção de opt-out/opt-in? Digo isso porque um evento futuro não é necessariamente um evento que você queira sempre promover aos convidados, já que você já promoveu o evento e sua série uma vez para eles por meio do primeiro evento.
Sim, no sentido de que o Evento sucessor mantém a configuração de recorrência. Por exemplo, no teste de fumaça da interface gráfica, a ocorrência original exibia Toda quinta-feira, e após a transição, o Tópico sucessor também exibia Toda quinta-feira, com a data avançada para a semana seguinte.
O que esta PR não adiciona é um relacionamento de série entre Tópicos que ligue o Tópico concluído e seu sucessor. O Tópico concluído se torna a ocorrência arquivada única, enquanto o sucessor carrega a recorrência para frente. Um relacionamento explícito de série/pai entre esses Tópicos poderia ser uma melhoria separada, se se provar útil.
Ele não carrega automaticamente todos os convidados/participantes para o novo Evento.
O sucessor só herda as pessoas que estavam going (participando) com o RSVP de recorrência/série ativado. Alguém que respondeu going apenas para a ocorrência individual permanece no Tópico concluído e não é adicionado ao sucessor.
Portanto, no momento, a escolha existente de responder ao RSVP da série atua efetivamente como o opt-in para ser incluído em futuros Eventos sucessores, em vez de haver outra configuração do site controlando isso.
Ótimo, se a recorrência for mencionada, isso já é suficiente e a categoria ou subcategoria também indica que o evento faz parte de uma série; só de pensar nisso, percebo o quão grande uma subcategoria de eventos pode ficar quando há eventos recorrentes, por isso a conversa sobre o fluxo de trabalho de arquivamento automático/automação mais cedo neste tópico.