Contrasync Docs

Appearance

Contract Save Flow - Fluxo de Salvamento ​

Visão Geral ​

O salvamento do contrato é feito manualmente via botão Salvar na toolbar. Os dados são mantidos no store local durante a edição e persistidos na API ao clicar salvar.

Fluxo Principal ​

Primeira vez (criar contrato) ​

  1. Usuário seleciona um workflow na toolbar
  2. Preenche dados nos steps (parts, model, documents, etc.)
  3. Clica no botão Salvar
  4. Modal aparece pedindo o nome do contrato
  5. Usuário preenche o nome e confirma
  6. POST /contracts é chamado com snapshot completo dos dados
  7. Backend retorna o contractId
  8. Store atualiza currentContractId
  9. Feedback de sucesso exibido

Próximas vezes (atualizar contrato) ​

  1. Usuário modifica dados em qualquer step
  2. Clica no botão Salvar
  3. PUT /contracts/{id} é chamado com snapshot completo
  4. Feedback de sucesso exibido

Carregar contrato existente ​

  1. Usuário acessa rota /contracts/:id/edit
  2. GET /contracts/{id}/detail carrega todos os dados
  3. Store é populado com dados de todos os steps
  4. Usuário continua editando de onde parou

Dados Salvos por Step ​

Step Parts ​

  • Array de ContractPart (person, role)

Step Model ​

  • modelConfig (templateId, partGroups, variableAssignments)
  • variableValues (valores preenchidos por grupo)
  • selectedTemplate (template escolhido)

Step Documents ​

  • Array de DocumentRequirement (name, isDownload, formats, etc.)
  • Configuração de download files

Step Upload ​

  • Arquivos enviados via endpoint separado (POST multipart)
  • Não faz parte do payload principal de save
  • Aparece automaticamente quando há documentos com isDownload: false

Step Revision ​

  • revisionConfig (reviewers com ordem e obrigatoriedade)

Step Signature ​

  • signatureConfig (groups de assinatura, ordem)

Composable: useContractSave ​

Responsabilidades:

  • Controlar visibilidade do modal de nome
  • Montar o payload de save a partir do store
  • Decidir entre POST (criar) e PUT (atualizar)
  • Gerenciar estados de loading e feedback
  • Expor isDirty para indicar mudanças não salvas

Estado no Store ​

Novas propriedades no contractDetail store:

  • isSaving: boolean, save em andamento
  • isDirty: boolean, mudanças não salvas
  • lastSavedAt: Date | null, timestamp do último save

Novos métodos:

  • saveContract(name): criar contrato (POST)
  • updateContract(): atualizar contrato (PUT)
  • save(): decide entre create/update
  • loadFullDetail(id): carregar contrato completo para edição
  • buildSavePayload(): montar payload a partir do estado atual

Upload de Arquivos ​

O step Upload funciona de forma independente do save geral:

  • Cada upload é enviado individualmente via POST /contracts/{id}/documents/{docId}/files
  • O contrato precisa estar salvo (ter currentContractId) antes de fazer upload
  • Se o contrato ainda não foi salvo, o botão de upload fica desabilitado

Botão Dinâmico na Toolbar ​

O botão principal da toolbar muda de label, cor e ação conforme o estado do contrato:

Lógica de decisão ​

Se contrato nunca salvo         → "Salvar" (default)
Se há alterações não salvas     → "Salvar" (default)
Se próximo step = revision      → "Enviar para Revisão" (primary/azul)
Se próximo step = upload/sig    → "Publicar" (success/verde)
Senão                           → "Salvar" (disabled)

Fluxo: Enviar para Revisão ​

  1. Usuário preenche todos os steps até documents
  2. Salva o contrato
  3. Botão muda para "Enviar para Revisão" (azul)
  4. Ao clicar: PUT /contracts/{id} com status: 'in_review'
  5. Backend detecta a mudança de status e envia e-mail para revisores
  6. Status muda para in_review
  7. Steps anteriores ficam bloqueados para edição (diretiva v-lock-step)

Fluxo: Publicar ​

  1. Contrato salvo e o próximo step é upload ou signature
  2. Botão muda para "Publicar" (verde)
  3. Ao clicar: PUT /contracts/{id} com status: 'published'
  4. Backend detecta a mudança de status e envia notificação para as partes
  5. Status muda para published
  6. Steps anteriores ficam bloqueados para edição

Bloqueio de steps anteriores ​

Quando o contrato entra em etapa de terceiros (revision, upload, signature):

  • Diretiva v-lock-step: remove do DOM botões de ação (add, edit, delete)
  • Diretiva v-lock-field: desabilita inputs, selects e textareas
  • O usuário pode navegar entre steps, mas não pode executar ações de edição
  • O workflow select na toolbar fica desabilitado

Regras ​

  1. O botão Salvar fica habilitado assim que um workflow é selecionado
  2. Na primeira vez, o modal de nome é obrigatório
  3. Nas próximas vezes, salva direto sem modal
  4. Navegação entre steps não aciona save, dados ficam no store local
  5. O step Upload só permite upload de arquivos se o contrato já foi salvo
  6. O nome do contrato pode ser editado no modal (futuro: inline na toolbar)
  7. Após "Enviar para Revisão" ou "Publicar", steps anteriores ficam bloqueados
  8. O botão dinâmico reflete o próximo step do fluxo, não o step atual