È previsto un modello di Community Workflow? Penso che potrebbe aggiungere molto valore a questa fantastica implementazione.
Non conosco i limiti tecnici, ma credo che Discourse Discovery possa abilitare/disabilitare questa funzionalità e riutilizzare la connessione all’ecosistema Discourse.
Ok, non l’avevo visto probabilmente perché devo aggiornare, grazie.
[Edit] Tutto ok dopo l’aggiornamento, grazie mille per quel manuale Bump 
Ciao @j.jaffeux, quando utilizzo il trigger “nuovo utente”, vorrei che l’azione successiva venisse eseguita solo se l’account del nuovo utente è stato attivato (per escludere i bot che registrano nuovi utenti). Devo usare lo stato “approvato” come filtro per questo scopo? Grazie.
E se la mia supposizione sopra è corretta, come devo specificare il valore TRUE? Come “True” o “T”? Grazie?
Sembra che abbia funzionato! Sono molto contento di questa funzione
Invece di trascinare e rilasciare user.approved, resta in modalità normale e seleziona user.approved nell’elenco; dovresti vedere questo:
È possibile configurare
trigger: una risposta di un utente in fase di staging in una categoria specifica
action: l’evento dell’argomento a cui l’utente in staging ha risposto viene chiuso automaticamente - in modo simile a
No, ci mancano alcuni dettagli a riguardo
Grazie — intendi dire che mancano ancora alcuni dettagli/punti dati nei Workflows per supportare questo caso d’uso?
Grazie, l’ho fatto, ma il filtro user.approved non sembra filtrare gli utenti che si sono registrati e hanno confermato il loro account.
Ho passato ore a cercare di far funzionare qualcosa con i workflow. Non riesco a far lavorare l’AI senza che generi un errore. Potrei cambiare il modello di AI e riprovare.
Quello che sto cercando di ottenere è qualcosa di simile a questo: (e molto pertinente alla recente discussione!)
In pratica, sto cercando di creare un workflow che tenti di riattivare casualmente i post che sono rimasti inattivi, ma che potrebbero aver bisogno di un follow-up.
Qualcuno ha qualche idea? Sono riuscito a ottenere i post usando il data explorer e a far generare un riassunto dall’AI. Non sono riuscito a far funzionare le tabelle dati e non sono arrivato alla fase del post automatico. Ma ci sono venuto abbastanza vicino.
La mia idea era dividerlo in diversi workflow:
Non sono sicuro di aver capito bene come usarlo, ma questo plugin ha un grande potenziale!
si trova nell’output, dove puoi definire i dati JSON in autonomia
@j.jaffeux In seguito alla mia domanda sopra, ho aperto una PR che aggiunge un’azione Event ai Workflows:
Viene aggiunta:
L’azione accetta un ID del topic, risolve l’evento dal primo post del topic e aggiorna l’evento tramite il percorso normale di sincronizzazione post-modifica/Event.
Ho testato la direzione originale del caso d’uso con:
Post creato → Event / Chiudi evento
utilizzando Input → topic.id.
Una risposta al topic dell’evento chiude l’evento mantenendo il topic stesso aperto, e la modifica appare in tempo reale nell’interfaccia.
La PR include la copertura di test unitari/integrativi, e la suite completa discourse-events ha superato con 1124 esempi / 0 fallimenti.
Questo risolve la parte relativa all’azione Event del caso d’uso menzionato sopra. Le condizioni basate su utente/categoria/origine email possono poi essere gestite separatamente dal trigger/condizioni del workflow.
Qualche consiglio su come etichettare automaticamente le risposte di un agente AI? Sto provando il seguente flusso di lavoro, ma non riesce a catturare le risposte dell’utente agente.
Per inciso, si tratta di un tag nascosto, ma l’agente appartiene a un gruppo che ha visibilità su di esso.
{
"id": "6",
"name": "My workflow",
"nodes": [
{
"id": "a8490306-e7e7-42e4-b909-851f3c4fbcba",
"type": "trigger:topic_created",
"typeVersion": "1.0",
"name": "When a new personal message is created",
"parameters": {
"topic_type": "personal_messages"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 178.6210678807947,
"y": -18.94519916824343
}
},
{
"id": "a80813a3-35cf-414e-98b8-9892f3eab496",
"type": "condition:filter",
"typeVersion": "1.0",
"name": "Keep PMs from Navigator",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "sender_is_navigator",
"operator": {
"type": "string",
"operation": "equals",
"singleValue": false
},
"leftValue": "={{ $json.post.username }}",
"rightValue": "Navigator"
}
]
},
"credentials": {},
"webhookId": null,
"position": {
"x": 290.515625,
"y": -18.281249999999993
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
},
{
"id": "acfcf305-1a04-4d2e-876c-48b015dc038c",
"type": "action:topic_tags",
"typeVersion": "1.0",
"name": "Add onboarding-initiated tag",
"parameters": {
"topic_id": "={{ $json.topic.id }}",
"operation": "add",
"tag_names": "onboarding-initiated",
"actor_username": "Navigator"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 513.1770833333333,
"y": -27.32031249999998
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
}
],
"connections": {
"Keep PMs from Navigator": {
"main": [
[
{
"node": "Add onboarding-initiated tag",
"type": "main",
"index": 0
}
]
]
},
"When a new personal message is created": {
"main": [
[
{
"node": "Keep PMs from Navigator",
"type": "main",
"index": 0
}
]
]
}
},
"settings": {},
"staticData": {},
"pinData": {},
"versionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"activeVersionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"versionCounter": 31
}
Mi piacerebbe molto un’azione automatica alla creazione di un evento: che l’autore vi venga iscritto di default. Questo permetterebbe di adattarsi a tutti i casi di figura, e in particolare per il mio utilizzo! 
abbiamo un nodo per l’evento della prossima settimana
Sì, penso che questo potrebbe integrarsi naturalmente nella stessa area Evento dei Workflows.
Nel mio PR attuale, FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub , ho aggiunto una sezione Evento nel builder dei workflow. Nella screenshot nella descrizione del PR, l’apertura di quel menu Evento offre attualmente due operazioni:
Queste sono deliberatamente le uniche due operazioni in quel PR perché è l’ambito della modifica che sto cercando di far rivedere.
Il tuo caso d’uso potrebbe potenzialmente aggiungere un’altra operazione a quello stesso menu Evento, qualcosa come Imposta presenza / Aggiungi partecipante. Un workflow potrebbe quindi utilizzare l’autore dell’evento come utente e impostare la sua presenza su Parteciperò quando l’evento viene creato.
Penso che sarebbe meglio implementarlo in modo generico - scegliendo l’utente e lo stato di presenza - piuttosto che avere un’azione speciale solo per “registrare automaticamente l’autore”.
Ci darò un’occhiata come follow-up, probabilmente come un PR separato in modo che il PR attuale per Apri/Chiudi Evento resti focalizzato.
Non avevo visto la tua risposta prima di pubblicare la mia qui sopra.
Dato che hai menzionato che un nodo Event arriverà la prossima settimana, testerò anche il mio PR corrente localmente contro gli altri rami PR aperti di discourse-events / Workflows che interessano la stessa area, anziché affidarmi solo alla CI su main.
Se dovessi trovare sovrapposizioni o conflitti reali, li segnalerò sul PR GitHub pertinente, piuttosto che appesantire questo argomento.
Credo che questo accada perché questo utente deve essere presente in pm_tags_allowed_for_groups; si potrebbe obiettare che il messaggio di errore potrebbe essere più chiaro… Mi impegnerò a migliorarlo.
MODIFICA: verrà migliorato da FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub