Está planejado um modelo de Community Workflow? Acredito que ele possa agregar muito valor a essa implementação fantástica.
Não conheço as limitações técnicas, mas acho que o Discourse Discovery pode habilitar/desabilitar essa funcionalidade e reutilizar a conexão com o ecossistema do Discourse.
Ok, eu não tinha visto, provavelmente porque eu precisava atualizar, obrigado.
[Edit] Tudo certo depois da atualização, muito obrigado por esse Bump manual 
Oi @j.jaffeux, ao usar o gatilho “novo usuário”, gostaria que a ação seguinte ocorresse apenas se a conta do novo usuário tiver sido ativada (para excluir os bots que registram novos usuários). Preciso usar o status “aprovado” como filtro para isso? Obrigado.
E, se minha suposição acima estiver correta, como devo especificar o valor TRUE? Como “True” ou “T”? Obrigado?
Parece que funcionou mesmo! Fico muito feliz com essa funcionalidade
Em vez de usar arrastar e soltar para user.approved, permaneça no modo simples e selecione user.approved na lista. Você deve ver o seguinte:
É possível ter
disparador: respostas de usuários em modo de rascunho em uma categoria específica
ação: o tópico ao qual o usuário em modo de rascunho respondeu é fechado automaticamente — de forma semelhante a
Não, estamos faltando alguns detalhes para isso.
Obrigado — você quer dizer que ainda faltam alguns detalhes/pontos de dados nos Workflows para suportar esse caso de uso?
Obrigado, eu fiz isso, mas o filtro user.approved não parece filtrar usuários que se registraram e confirmaram suas contas.
Estou tentando fazer algo funcionar há horas usando os fluxos de trabalho. Não consigo fazer a IA funcionar sem que ela lance um erro. Talvez eu troque o modelo de IA e tente novamente.
O que estou tentando alcançar é algo assim: (e muito relevante para a discussão recente!)
Basicamente, estou apenas tentando criar um fluxo de trabalho que tente obter algum reenvolvimento aleatório em publicações que estão paradas, mas que talvez precisem de uma publicação de acompanhamento.
Alguém tem alguma ideia? Consegui obter as publicações usando o explorador de dados e consegui obter um resumo da IA. Não consegui fazer as tabelas de dados funcionarem e não cheguei à etapa de publicação automática. Mas cheguei perto.
Minha ideia foi dividir isso em vários fluxos de trabalho:
Não tenho certeza se entendi como usá-lo, mas este plugin tem muito potencial!
está na saída, onde você pode definir os dados JSON por conta própria
@j.jaffeux Seguindo minha pergunta acima, abri um PR que adiciona uma ação de Evento aos Workflows:
Ele adiciona:
A ação recebe um ID de tópico, resolve o evento a partir da primeira postagem do tópico e atualiza o evento através do caminho normal de sincronização de edição de postagem/Evento.
Testei a direção original do caso de uso com:
Postagem criada → Evento / Fechar evento
usando Input → topic.id.
Uma resposta ao tópico do evento então fecha o evento, mantendo o próprio tópico aberto, e a alteração aparece em tempo real na interface.
O PR inclui cobertura de testes unitários/integração, e a suíte completa de discourse-events passou com 1124 exemplos / 0 falhas.
Isso atende à parte da ação de Evento do caso de uso mencionado acima. As condições de usuário/categoria/origem de e-mail podem ser tratadas separadamente pelo gatilho/condições do workflow.
Algumas dicas sobre como aplicar automaticamente tags às respostas de um agente de IA? Estou tentando o seguinte fluxo, mas ele não está capturando as respostas do usuário do agente.
Vale ressaltar que esta é uma tag oculta, mas o agente está em um grupo que tem visibilidade dela.
{
"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
}
Eu adoraria uma ação automática na criação de um evento: que o autor seja inscrito diretamente por padrão. Isso permitiria se adaptar a todos os cenários, e particularmente para o meu uso! 
temos um evento programado para a próxima semana
Sim, acho que isso poderia se encaixar naturalmente na mesma área de Event dos Workflows.
No meu PR atual, FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub, adicionei uma seção Event no construtor de workflows. No screenshot da descrição do PR, ao abrir esse menu de Event, atualmente são apresentadas duas operações:
Essas são deliberadamente as únicas duas operações nesse PR, pois esse é o escopo da mudança que estou tentando ter revisada.
Seu caso de uso poderia potencialmente adicionar outra operação a esse mesmo menu de Event, algo ao longo das linhas de Set attendance / Add attendee. Um workflow poderia então usar o autor do evento como o usuário e definir sua presença como Going quando o evento é criado.
Acho que seria melhor implementado de forma genérica — escolhendo o usuário e o estado de presença — em vez de ter uma ação especial apenas para “registrar automaticamente o autor”.
Vou dar uma olhada nisso como um acompanhamento, provavelmente como um PR separado, para que o PR atual de Open/Close Event permaneça focado.
Eu não tinha visto sua resposta antes de postar a minha acima.
Como você mencionou que um nó de Evento será lançado na próxima semana, também vou testar meu PR atual localmente contra os outros ramos de PR abertos do discourse-events / Workflows que tocam na mesma área, em vez de me basear apenas no CI contra o main.
Se eu encontrar alguma sobreposição ou conflito real, vou relatá-lo no PR relevante do GitHub, em vez de poluir este tópico.
Acho que isso acontece porque esse usuário precisa estar em pm_tags_allowed_for_groups, e, argumentavelmente, a mensagem de erro poderia ser melhor… Vou melhorar.
EDIÇÃO: será melhorado por FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub