DocsExecutarAprovação manual

Aprovação manual

Adicione uma porta de aprovação manual a qualquer passo: responda através da caixa de entrada, e-mail ou API, edite valores em linha e rejeite automaticamente no tempo limite.

manual aprovation codifica "esperar que alguém confirme antes de continuar" como um modificador de passo: quando a execução atinge um passo configurado com ele, ele pausa e só executa o corpo passo após a aprovação. Até então, o sistema não realiza nenhuma ação para esse passo ou qualquer coisa a jusante dele.

Configuração

yaml

  - step: apply_changes
    agent: executor
    input: "把已审核的变更应用到线上"
    manual_approval:
      enabled: true
      approvers:            # 平台用户 ID；留空 = 发起人 / 有执行权限者可批
        - "usr_team_lead"
      timeout: 86400        # 秒；24 小时无人批复自动拒绝
      approval_message: |
        请确认是否应用本轮变更。
        拒绝或超时不会做任何线上修改。

Ele pode anexar a qualquer etapa (agente, código, sub workflow, etc.), e é frequentemente usado em um passo de código leve que apenas imprime status, agindo como um "portado humano" puro

Parâmetros

Campo	Tipo	Padrão	Designação das mercadorias
`enabled`	`boolean`	—	Se habilitar a porta de homologação (obrigatório)
`approvers`	`string[]`	`[]`	Especificar revisores ( IDs de usuário da plataforma). Quando não vazio, apenas usuários da lista e administradores podem decidir — nem mesmo a pessoa que iniciou a execução, o que naturalmente obriga à separação de funções; quando vazio, a pessoa que iniciou a execução ou qualquer colaborador com permissão de execução no workflow pode decidir
`timeout`	`long`	`3600`	Tempo em segundos. Se ninguém decidir pelo prazo, é automaticamente rejeitado e marcado TIMED OUT
`approval_message`	`string`	`null`	A nota mostrada ao revisor, que aparece no cartão de aprovação e em e-mails de notificação
`reviewable_actions`	`array`	`[]`	Grupos de formulários de aprovação editáveis, onde o revisor pode selecionar um subconjunto e editar valores antes de aprovar (ver abaixo)

Processo de aprovação

Quando a execução atinge um passo configurado com a aprovação manual, ela pausa e o estado de execução torna-se AWAITTING APPROVAL
Um registro de aprovação é criado e o relógio de timeout começa; o console recebe um pedido de aprovação em tempo real sobre WebSocket, e o revisor também pode receber um e-mail de notificação
O revisor decide através de um dos três canais: a lista de aprovação no aplicativo, um link de um clique em uma mensagem, ou a API
Aprovar → o passo continua; rejeitar → o passo é tratado como falhou (você pode ligar um ramo de notificação com on failure); tempo limite → rejeitado automaticamente

Canal 1: a lista de aprovação no aplicativo

A consolaHomologaçãopágina lista todas as aprovações visíveis para você, com visualização de cartão e tabela e filtragem de status. Você pode anexar uma nota ao aprovar ou rejeitar, e a nota é salva no registro de aprovação. As aprovações configuradas com reviewable actions se expandem em uma tabela selecionável e editável.

Canal 2: notificações por e-mail e links de um clique

Com notificações de e-mail on, o revisor (a pessoa que iniciou a execução quando aprovadores não é especificado) recebe um e-mail em seu endereço de conta contendo: o workflow e os nomes dos passos, o ID de execução, o número de ações reavaliadas, um aviso de tempo ("auto-rejeitado em aproximadamente N horas"), o texto de aprovação mensage, e um link para a lista de aprovação.

Em mensagens que não podem definir cabeçalhos personalizados, como e-mail, Slack e Telegram, você também pode incorporar um link de decisão de um clique:

text

GET https://braidrun.com/api/webhook-trigger/approval/{approvalId}/approve?api_key=dyk_...
GET https://braidrun.com/api/webhook-trigger/approval/{approvalId}/reject?api_key=dyk_...

O link é autenticado com uma API Key (APPROVAL RESPOND escopo), colocado no parâmetro consulta api key. Para evitar gatilhos acidentais por bots link-preview (Slack desfurls, e-mail-client prefetching), o primeiro aberto só renderiza uma página de confirmação e não realiza nenhuma ação; a decisão é tomada apenas quando você clica no botão confirmar e a solicitação repete com confirm=1. A página carrega cabeçalhos no-store e noindex para evitar cache ou replay motor de busca.

Canal 3: a API

A API aberta v1 fornece 5 endpoints de aprovação, todos requerendo o escopo APPROVAL RESPOND:

Ponto final	Objecto
`GET /api/v1/approvals`	Lista de homologação, filtrada pelo estado
`GET /api/v1/approvals/{id}`	Detalhes da homologação
`GET /api/v1/approvals/execution/{executionId}`	Procurar as aprovações associadas a uma execução
`POST /api/v1/approvals/{id}/approve`	Aprovar; o corpo pode incluir comentários e itens editados
`POST /api/v1/approvals/{id}/reject`	Rejeitar; o corpo pode incluir comentários

bash

# 批准（可附备注）
curl -X POST https://braidrun.com/api/v1/approvals/<approval-id>/approve \
  -H "Authorization: Bearer dyk_..." \
  -H "Content-Type: application/json" \
  -d '{"comment": "确认执行"}'

# 拒绝
curl -X POST https://braidrun.com/api/v1/approvals/<approval-id>/reject \
  -H "Authorization: Bearer dyk_..." \
  -H "Content-Type: application/json" \
  -d '{"comment": "本轮预算已用完"}'

editedItems submete o subconjunto selecionado/editado pelo nome do grupo, combinando a estrutura do formulário de aprovação editável na próxima seção; omitindo-o aprova tudo como-is.

Formulários de homologação editáveis (reviewable actions)

Algumas aprovações são por recomendação: fora de um lote de recomendações que você executa apenas algumas, e algumas linhas até mesmo precisam de mudanças de valor. reviewable actions transforma essas aprovações em uma tabela — o revisor verifica as linhas a serem executadas, edita colunas marcadas editáveis: true diretamente (por exemplo, alterando uma licitação), e então clica em aprovar.

yaml

    manual_approval:
      enabled: true
      timeout: 86400
      approval_message: |
        请审核本轮调价建议：可勾选要执行的行，并直接修改建议出价。
      reviewable_actions:
        - name: raise_bid
          title: 加价建议
          source_var: raise_bid_file           # 变量值 = 建议清单 JSON 数组文件路径
          output_var: raise_bid_approved_file  # 批准后 = 勾选/编辑后的子集文件路径
          key_field: item_id
          columns:
            - { key: item_name, label: 名称, editable: false }
            - { key: current_bid, label: 当前出价, type: number, editable: false }
            - { key: proposed_bid, label: 建议出价, type: number, editable: true }
            - { key: reason, label: 理由, editable: false }

name — O nome interno do grupo, também usado como prefixo de arquivo de saída (após a aprovação do motor escreve revised <name>.json)
source_var — Aponta para uma variável cujo valor é a lista de recomendações gerada por um passo a montante (o caminho para um arquivo de array JSON)
output_var — Uma variável definida após a aprovação, cujo valor é o caminho para o arquivo de subconjunto selecionado/editado; faça com que a etapa de execução a jusante o leia em seu lugar, e processará apenas as linhas aprovadas
key_field — O campo de identificação da linha, usado para alinhar as linhas após a edição; se ausente, as linhas são alinhadas pelo índice do array
columns — As definições da coluna da tabela; colunas com editável: true pode ser alterada pelo revisor, e tipo: o número renderiza como uma entrada numérica

Validação do lado do servidor

O subconjunto submetido é validado lado do servidor: os dados que não pertencem a nenhum grupo são filtrados para fora; quando key field é definido, cada linha deve mapear para uma entrada na lista original, de modo que a fabricação de uma linha inexistente não pode passar; colunas com editável: false manter seus valores originais, e as mudanças para eles são ignoradas. Quando um grupo não tem linhas marcadas, um array vazio é escrito para fora, e o passo a jusante lida com isso como "vazio, pule"

Rejeição e tempo- limite: zero alterações

A principal promessa da porta de aprovação é que o sistema não realiza nenhuma ação antes da aprovação. Em caso de rejeição ou tempo- limite

O corpo do passo não corre, e passos a jusante que dependem dele não são acionados
Você pode usar um branch on failure para anexar uma notificação "aprovação rejeitada" ou etapa de arquivo
Um tempo limite é automaticamente rejeitado pelo sistema, com o decisor registrado como sistema; cada decisão de aprovação (incluindo o decisor, tempo e nota) é escrita para o diário de auditoria

Quando o serviço for reiniciado

Os registos de aprovação são armazenados de forma duradoura. Após o reinício do serviço, as aprovações pendentes são restauradas conforme o caso, o relógio de timeout continua até o prazo original, e os revisores podem decidir como de costume.