Sono molto entusiasta della funzionalità workflow e prevedo di utilizzarla per espandere notevolmente le capacità del mio forum.
Penso che questa singola funzionalità, se ben mantenuta, attirerà una vasta comunità che creerà automazioni; per questo motivo, ritengo che dovrebbe esserci una categoria dedicata agli workflow in questo forum meta. Gli utenti potrebbero condividere workflow, chiedere aiuto nella loro creazione o fare richieste di nodi.
Personalmente, vorrei vedere alcune funzionalità:
invio di messaggi agli utenti in chat
creazione/eliminazione di categorie
API per plugin (ne parlerò più avanti)
E probabilmente ne arriveranno altre man mano che esplorerò nuove idee.
Il forum n8n ha un plugin personalizzato che consente di visualizzare i flussi in un thread. Una funzionalità del genere sarebbe ottima per la categoria workflow, favorendo la collaborazione e il troubleshooting/supporto.
n8n ha anche dei nodi Discourse; sarebbe fantastico avere una parità di funzionalità e, ancora meglio, un’interoperabilità con quei nodi, ad esempio utilizzando una chiamata di un nodo n8n come trigger per un workflow.
Con API per plugin intendo la possibilità di aggiungere nodi tramite un plugin. Un’idea che ho in mente è che il plugin di gamification potrebbe essere utilizzato per espandere la funzionalità dei punti, consentendo comportamenti dinamici come l’aggiunta o la rimozione di punti in base all’interazione con il forum.
Ora che è attivo nella versione LTS, lascerò alcune note in questo thread riguardo alle cose che incontro e che considero funzionalità mancanti o bug (mancanti nel senso che non esiste parità di funzionalità con n8n)
Il blocco Richiesta HTTP non ha una funzione di paginazione
I blocchi di trasformazione dei dati split e aggregate di n8n non hanno equivalenti nei flussi di lavoro di Discourse
Penso che la proposta sia ragionevole. Sono d’accordo, c’è probabilmente ampio spazio per condividere workflow qui. Lo considereremo sicuramente.
Forse meriterebbe di avere una sua categoria in Customization, ad esempio #customization/workflows.
Nel frattempo, suggerisco due cose:
Contribuisci a questo argomento: Show us your Workflows se vuoi semplicemente chiacchierare e condividere in modo molto informale.
Usa gli argomenti in #customization/extras con il tag #workflows per condividere in modo più curato, ad esempio per condividere workflow che ritieni meritino maggiore attenzione, supporto e manutenzione nel tempo.
I tag sono un buon modo per far nascere una nuova categoria. Se vediamo che questa acquisisce slancio, sarebbe un passo naturale promuoverla a nuova categoria e spostare lì gli argomenti con quel tag.
Penso che questo sarebbe un buon argomento in Contribute > Feature con il tag workflows. Se hai suggerimenti per migliorare la funzionalità dei workflow nel suo complesso, è un buon modo per registrarli e permettere alle persone di discuterne e votare.
Stai usando la release LTS / ESR (esr)?
Penso che, dato il tuo interesse in questo ambito, sarebbe utile passare a latest. In questo modo, avrai un ciclo di feedback più rapido man mano che le cose continuano a evolversi.
Mi sono perso questo passaggio, ma è già così: chat, assegnazione, votazione sui topic, IA… sono tutti plugin che utilizzano già l’API del plugin workflows.
Praticamente ogni idea a cui sono arrivato richiede il nodo di richiesta HTTP a causa della discrepanza tra l’API e l’output dei nodi.
Ad esempio, sto cercando di creare un modo per i moderatori/amministratori e altri gruppi selezionati di poter aggiungere +Xp o -Xp per aggiungere o rimuovere punti agli utenti rispondendo loro, sia nei DM che nei post pubblici. Il problema è che non esiste un nodo che posso usare per ottenere l’id del post del messaggio a cui sto rispondendo.
Se voglio ottenere l’userid del post a cui sto rispondendo, ho bisogno dell’id di quel post. Ottenere il mio post non rivela alcun valore reply_to_id, ottenere l’argomento non rivela un elenco di post con gli id. L’unico modo per ottenere l’id è tramite l’API e le API hanno dei limiti di velocità (rate limits).
Nella sua forma attuale, il blocco di richiesta HTTP è quasi inutile perché non ha controlli per la paginazione o gli intervalli. Il blocco di attesa non risolve questo problema perché i singoli nodi eseguono tutti gli elementi e non c’è un nodo di loop per forzare la paginazione degli elementi.