Ciao,
Gli eventi ricorrenti sono eventi individuali, tuttavia quando ne crei uno non vengono creati argomenti individuali.
Quindi se fai clic su uno di quegli eventi ricorrenti per parteciparvi, la tua partecipazione è presente su tutti gli eventi.
La creazione di un evento ricorrente non dovrebbe creare eventi/argomenti individuali con la stessa base del primo evento?
Questa è decisamente una richiesta di funzionalità. Ti capisco, sarebbe bello se si potesse scegliere un evento particolare in una sequenza.
Ci sono novità in merito?
È davvero necessario creare un nuovo argomento per ogni evento, piuttosto che avere un unico argomento per l’evento che controlla una serie di eventi visibili nel calendario.
Al momento, l’unico workaround fattibile è creare manualmente una serie di nuovi argomenti. Questo, naturalmente, riempie il feed degli ultimi in modo molto fastidioso (il che richiede una mitigazione in qualche modo) e richiede di fare attenzione a non inviare troppe notifiche. Immagino che questo metta in luce alcune delle sfide legate alla realizzazione di questa funzionalità.
Sarebbe accettabile se gli eventi secondari in un argomento avessero un aspetto diverso, come ad esempio un contorno, tramite eventBorderColor e eventBackgroundColor?
Puoi simulare la sovrapposizione combinando:
| Proprietà | Primario (confermato) | Secondario / provvisorio |
|---|---|---|
| eventBackgroundColor | solido | diverso / chiaro |
| eventBorderColor | uguale al riempimento | forte contrasto |
| stile del bordo | solido | tratteggiato |
| opacità | 1 | 1 |
Questo crea una gerarchia visiva senza bisogno di una vera sovrapposizione.
Idea carina, ma non credo che sarà sufficiente: ogni evento di una serie ha davvero bisogno del proprio RSVP, di informazioni supplementari e di una discussione.
L’RSVP verrebbe sostituito dal poll, così tutti gli eventi nel topic sarebbero standalone. Gli eventi riguarderebbero tutti la stessa cosa, la complessità: fissare un orario tra diverse opzioni disponibili.
Non è davvero una serie né qualcosa che si può realizzare in Outlook.
È la speciale ingrediente che spinge un’istituzione, come l’università in cui mi trovo, ad allontanarsi dalle serie difensive e false di Outlook e a rivolgersi a Discourse.
Torno a parlare di questo dopo aver utilizzato il plugin rivisto negli ultimi mesi: ora funziona piuttosto bene, dato che abbiamo più opzioni di ricorrenza, in particolare il giorno X del mese e la possibilità di rispondere all’invito per l’evento o per la serie.
Tuttavia, rimane un problema fondamentale: l’archiviazione dei contenuti dell’ultimo evento.
Il caso d’uso è un evento ricorrente che ha diversi post/discussioni associate. Questo può includere file allegati e immagini. L’esempio più ovvio è una riunione di lavoro regolare.
Al momento, questo caos risultante deve essere ordinato manualmente in un modo o nell’altro, poiché ciò che fa la ricorrenza è semplicemente cambiare la data dell’evento e cancellare la risposta all’invito. Le opzioni manuali sono:
Sfortunatamente, nessuna di queste è ottima.
Vorrei che la ricorrenza preservasse intatto l’argomento dell’evento corrente, ma una volta completato, il plugin creerebbe un nuovo argomento per il prossimo evento.
Questo manterrebbe il flusso piacevole e garantirebbe automaticamente che venga conservato un archivio appropriato dell’evento passato, oltre a fornire un argomento “pulito” per il nuovo evento.
Il prezzo da pagare (a parte la complessità aumentata) sarebbe che l’evento attivo avrebbe un nuovo URL. Potrei vedere questo come potenzialmente un problema in alcuni casi.
Ciao, questo implica che dovrai attendere la chiusura dell’evento corrente della serie di eventi ricorrenti prima di poter ti iscrivere al prossimo evento?
La maggior parte dei plugin per eventi su Joomla su cui ho lavorato crea direttamente la serie di eventi, proprio come la tua idea qui, che creerebbe argomenti/URL individuali per ogni evento, il che secondo me è il modello corretto.
Offrire l’opzione di vietare l’iscrizione a meno di x giorni dagli eventi ricorrenti sarebbe anche pratico.
Per quanto riguarda l’archiviazione, gli eventi non risiedono principalmente in una loro sotto-categoria o non sono abbastanza etichettabili da mantenerli insieme e consentire un’azione automatizzata su di essi?
Sì, ma questo non è diverso dalla situazione attuale, in cui è possibile rispondere all’invito (RSVP) per l’evento corrente o per l’intera serie.
Intendi un’azione per clonare l’evento e spostare le risposte, o qualcosa di simile? Forse i Workflows potrebbero farlo; ho intenzione di studiarlo più a fondo.
A mio parere, rispondere all’intera serie è meno utilizzato nella mia esperienza con gli eventi rispetto alla possibilità di iscriversi a un evento specifico in seguito; tuttavia, entrambe le opzioni sono importanti.
Sì, tuttavia non vedo nella mia installazione alcun workflow che esegua questa operazione.
Si tratta forse di una richiesta di funzionalità a sé stante e interessante al di là dell’ambito degli eventi, e potrei/dovrei creare un altro topic per questo.
Avremmo bisogno di un’azione di archiviazione automatica attivata da determinate condizioni; in questo caso sarebbe “la data dell’evento o la data di fine, se presente”, che è nel passato o il topic è chiuso da x giorni, con forse un ritardo selezionabile prima che l’azione si verifichi, in modo che il topic dell’evento possa rimanere visibile per consentire alle persone di commentare per alcuni giorni dopo l’evento.
Ci sono stati alcuni progressi in merito.
Un trigger Event ended per i Workflows è stato ora integrato:
Inoltre, i Workflows dispongono già di un’azione Topic che può Get un topic esistente e Create uno nuovo, ed è presente un nodo Wait. Pertanto, gran parte del passaggio proposto potrebbe già essere componibile come workflow, senza necessitare di una funzione di archiviazione dedicata specifica per l’evento.
Qualcosa del tipo:
Event ended → Wait → Topic / Get → Topic / Create
potrebbe potenzialmente creare un topic di successione utilizzando i dati di titolo/corpo/categoria del topic precedente, lasciando intatto il topic completato come archivio.
Ciò che andrebbe ancora verificato è esattamente quali parti del topic vecchio dovrebbero essere copiate automaticamente, ad esempio tag, upload, stato di ricorrenza dell’evento e se le risposte dovrebbero essere spostate o semplicemente lasciate lì.
Ho anche un PR aperto che introduce un’azione Event ai Workflows:
Il PR base aggiunge Close event e Open event, e ho un follow-up impilato che aggiunge Set attendance:
L’azione è strutturata in modo da poter aggiungere ulteriori operazioni specifiche per gli eventi come follow-up separati, ove abbia senso.
Bene, grazie per lo sforzo. Le condizioni di chiusura possono essere utili, ma potrebbero non essere del tutto applicabili alla situazione originale.
Una categoria di eventi può crescere molto, soprattutto con gli eventi ricorrenti, e avrebbe senso fornire un modo per archiviare o spostare automaticamente in una categoria di argomenti passati o in un archivio qualsiasi evento chiuso da x giorni.
Ma questa questione di archiviazione dipende dalla decisione di far sì che gli eventi ricorrenti diventino argomenti individuali collegati all’argomento principale dell’evento.
Ho aperto una PR che implementa questa funzionalità come modalità ricorrente di Evento opzionale:
Aggiunge un’impostazione di sito discourse_post_event_recurring_topic_mode con due opzioni:
reuse_topic — il comportamento esistente e predefinitocreate_next_topic — preserva l’argomento dell’occorrenza completata e crea un nuovo argomento per la prossima occorrenzaCon create_next_topic, quando un’occorrenza termina, l’argomento completato viene mantenuto con il suo Evento fissato a quell’occorrenza e la ricorrenza rimossa. Viene quindi creato un argomento successore per la prossima ricorrenza, preservando il titolo, il corpo, la categoria, i tag e l’autore originali, mentre le date dell’Evento vengono aggiornate.
I test automatizzati coprono anche la semantica del passaggio delle RSVP: la partecipazione ricorrente going viene trasferita all’argomento successore, mentre la partecipazione una tantum rimane con l’occorrenza completata.
Il passaggio è anche transazionale, quindi se la creazione dell’argomento successore fallisce, l’occorrenza rimane in sospeso e può essere ritentata, invece di essere lasciata parzialmente completata.
Questo implementa specificamente il modello “crea il prossimo argomento quando l’occorrenza corrente termina”. Non genera ancora argomenti individuali per tutte le occorrenze future in anticipo, che è il modello alternativo menzionato sopra da @opcourdis.
Il comportamento esistente rimane quello predefinito, quindi questa è un’opzione opt-in per i siti che vogliono che l’argomento dell’Evento completato funga da archivio.
Grazie, questo modello funziona già molto bene per gli organizzatori, che ora possono sapere con certezza di non dover ricreare un evento ogni volta, e offre anche la sicurezza che le persone non si iscriveranno in anticipo, poiché gli organizzatori possono sempre annullare un evento per determinati motivi.
Il modello di creazione in anticipo che ho proposto funziona anche per molti casi e complementerebbe il tuo modello di successione degli eventi.
A proposito, per la PR sulla modalità di successione degli eventi:
1° Le persone che si iscrivono al nuovo evento sanno ancora che l’argomento/evento fa parte di una serie di eventi ricorrenti, come l’evento/argomento originale?
2° L’invito automatico degli ospiti originali all’evento è un’opzione di opt-out/opt-in? Lo dico perché un evento futuro non è necessariamente un evento che si desidera sempre promuovere agli ospiti, dato che l’evento e la sua serie sono già stati promossi loro una volta tramite il primo evento.
Sì, nel senso che l’Evento successivo mantiene la configurazione della ricorrenza. Ad esempio, nel test di fumo dell’interfaccia grafica, l’occorrenza originale mostrava Ogni giovedì e, dopo il passaggio al nuovo evento, anche l’Argomento successivo mostrava Ogni giovedì, con la data aggiornata alla settimana successiva.
Ciò che questo PR non aggiunge è un rapporto di serie separato tra Argomenti che colleghi l’Argomento completato e il suo successore. L’Argomento completato diventa l’occorrenza archiviata a partecipazione singola, mentre il successore porta avanti la ricorrenza. Un rapporto esplicito di serie/genitore tra quegli Argomenti potrebbe essere un miglioramento separato, se si rivelasse utile.
Non trasferisce automaticamente ogni ospite/partecipante al nuovo Evento.
Il successore eredita solo le persone che avevano risposto parteciperò con l’opzione RSVP per la serie/ricorrenza abilitata. Chi ha risposto parteciperò solo all’occorrenza individuale rimane sull’Argomento completato e non viene aggiunto al successore.
Pertanto, al momento, la scelta esistente di RSVP alla serie funziona di fatto come opt-in per essere trasferiti agli eventi successori futuri, anziché esserci un’impostazione del sito che lo controlli in modo separato.