snglpi/docs/casosdeuso.md

# Casos de Uso 

## Capitulo 1 - Abertura do chamado

No reino da CAOA, um usuario abre um chamado no ServiceNow.
O oraculo da integracao observa o novo registro e grava no banco intermediario.
Sem demora, o chamado atravessa o portal SN -> GLPI.
No GLPI, o ticket nasce com seu vinculo e recebe seu identificador.
De volta ao ServiceNow, o campo "Ticket Externo" e preenchido com o ID GLPI.

Resultado esperado:

1. Chamado criado no GLPI.
2. `ticket_sync` em `synced/synced`.
3. Ticket Externo preenchido no SN.

---

## Capitulo 2 - O chamado fora do escopo

Um atendente da Sothis analisa o chamado e percebe:
"Problema relacionado a Rede e nao Telefonia".

Ele registra essa justificativa na nota de solucao do GLPI (fora do escopo).
A integracao reconhece o tipo de solucao configurado para fora de escopo.
Entao envia a justificativa para o ServiceNow como nota.
Nao encerra o chamado no SN nesse passo de negocio de fora de escopo.
O chamado sai do monitoramento automatico da integracao.

Estado final esperado no banco intermediario:

1. `glpi_sync_status = 'closed'`
2. `sn_sync_status = 'ignored'`

Interpretacao operacional:

1. Chamado nao sera mais tratado pela fila automatica da integracao.
2. Evita retrabalho e loops de sincronizacao.

---

## Capitulo 3 - Encerramento definitivo

Quando um chamado chega ao encerramento definitivo no GLPI (`status=6`),
o cron de fechamento detecta o estado final e executa:

1. Publica no SN a mensagem:
   - "Chamado encerrado definitivamente. Reabertura deste chamado nao sera atendida. Caso necessario, abra um novo chamado."
2. Nao altera o status do chamado no SN.
3. Marca `ticket_sync` como `closed/closed` para retirar do monitoramento.

Resultado esperado:

1. Nao fica chamado fechado no GLPI e aberto no SN.
2. Nao ocorre tentativa de reabertura automatica para GLPI `6`.

---

## Capitulo 4 - Comunicacao entre os reinos (comentarios)

No salao da CAOA (ServiceNow), o usuario escreve:
"Equipe Sothis, conseguimos reproduzir o erro as 14h10."

A mensagem atravessa o portal SN -> GLPI e aparece como followup.
Do outro lado, no castelo da Sothis (GLPI), o atendente responde:
"Recebido. Estamos validando o circuito."

A resposta volta pelo portal GLPI -> SN como comentario.
Os escribas da integracao registram origem e destino para evitar duplicidade.

Resultado esperado:

1. Comentario SN vira followup GLPI.
2. Followup GLPI vira comentario SN.
3. Sem mensagens duplicadas no vai-e-volta.

---

## Capitulo 5 - As tarefas e os segredos do reino

No reino da CAOA, toda `work_note` do SN e uma ordem de batalha.
Essas ordens sao enviadas ao GLPI como tarefas visiveis para o time tecnico.

No reino da Sothis, tarefas internas do GLPI sao consideradas secretas.
Elas nao atravessam o portal para o SN.
Somente followups/comentarios publicos participam da comunicacao entre reinos.

Resultado esperado:

1. Toda `work_note` SN vira task GLPI.
2. Task criada no GLPI nao volta para SN.
3. O SN recebe somente comentarios/followups do GLPI.

---

## Capitulo 6 - A solucao no reino Sothis (GLPI)

Quando o atendente Sothis conclui o trabalho tecnico no GLPI,
ele registra a solucao e coloca o chamado em **Solucionado** (`status=5`).

O cron da integracao observa esse estado e realiza:

1. Busca a nota de solucao do GLPI.
2. Resolve o chamado correspondente no SN.
3. Atualiza o estado local para `solved/solved`.

Se o chamado no SN estiver em estado que bloqueia encerramento
(como espera/aguardando), a integracao primeiro ajusta para em atendimento
e depois aplica a resolucao.

Resultado esperado:

1. GLPI solucionado reflete SN resolvido.
2. A nota de resolucao do GLPI vira base do fechamento no SN.
3. Chamado continua monitorado ate o encerramento definitivo.

---

## Capitulo 7 - A solucao vinda do reino CAOA (SN)

Quando a CAOA marca o chamado como resolvido no SN,
a integracao **nao fecha o chamado no GLPI automaticamente**.

Em vez disso:

1. Uma nota informativa e adicionada no GLPI.
2. O chamado sai do monitoramento automatico de status.

Essa regra evita conflito de fluxo e protege o time tecnico de mudancas
de estado inesperadas do outro reino.

Resultado esperado:

1. GLPI recebe contexto da resolucao do SN.
2. Nao ocorre fechamento forcado no GLPI por esse evento.
3. Fluxo fica estavel para evitar reaberturas em cadeia.

---

## Capitulo 8 - Regras de ouro para os guardioes dos dois reinos

1. Comentario e diplomacia entre reinos: sempre pode cruzar o portal.
2. Task do SN e ordem operacional para Sothis: cruza para o GLPI.
3. Task interna do GLPI e sigilo tecnico: nao cruza para SN.
4. GLPI `5` resolve SN.
5. GLPI `6` encerra monitoramento e publica aviso definitivo no SN.
6. Reabertura automatica:
   - permitida se GLPI estiver `5`
   - bloqueada se GLPI estiver `6`
7. Fora de escopo:
   - justifica no SN
   - remove do monitoramento
   - estado final `closed/ignored`.