# Suporte — Modelagem de Dados

> Estrutura de dados do módulo. Fonte: schema real do banco
> `prefeituras_v5`.

---

## 1. `supports` (tickets do sistema órfão)

Criada por `v6/database/migrations/2018_12_26_140430_create_supports_table.php`.

| Coluna | Tipo | Null | Default | Observação |
|---|---|---|---|---|
| `id` | integer | não | `nextval('supports_id_seq')` | PK |
| `protocolo` | varchar(191) | **não** | — | ex.: `DU25A2026` |
| `users_id` | integer | sim | — | **FK** -> `users(id)` `ON DELETE CASCADE` |
| `supports_categories_id` | integer | sim | — | **FK** -> `supports_categories(id)` `ON DELETE CASCADE` |
| `assunto` | varchar(191) | **não** | — | |
| `descricao` | text | **não** | — | |
| `created_at` / `updated_at` | timestamp(0) | sim | — | |
| `deleted_at` | timestamp(0) | sim | — | `SoftDeletes` |

FKs: `supports_users_id_foreign` e
`supports_supports_categories_id_foreign`, ambas com `ON DELETE CASCADE`.

> A coluna `users_id` é nullable, mas o controller sempre preenche
> (`$data['users_id'] = Sentinel::getUser()->id`).

## 2. `supports_categories`

Criada por `v6/database/migrations/2018_12_26_140420_create_supports_categories_table.php`.

| Coluna | Tipo | Null | Default |
|---|---|---|---|
| `id` | integer | não | seq |
| `name` | varchar(191) | **não** | — |
| `slug` | varchar(191) | **não** | — |
| `created_at` / `updated_at` | timestamp(0) | sim | — |
| `deleted_at` | timestamp(0) | sim | — |

O model `SupportCategory` **não** usa `SoftDeletes`, apesar de a coluna
existir.

### 2.1 Conteúdo semeado

`v6/database/seeds/SupportCategorySeeder.php` faz `DB::table('supports_categories')->delete()`
e insere 4 categorias (o `id` está comentado no código, ou seja, é
autoincremento):

| name | slug |
|---|---|
| Dúvida | `duvida` |
| Erro | `erro` |
| Sugestão | `sugestao` |
| Elogío | `elogio` |

> A grafia **"Elogío"** (com acento no "í") está duplicada no código do
> seeder e gera slugs diferentes a cada execução.

## 3. `suppliers` (dependência do módulo `fornecedores`)

A página de suporte viva lê desta tabela. Detalhamento completo no dossiê
do módulo `fornecedores`; aqui apenas o essencial:

| Coluna | Tipo | Null | Observação |
|---|---|---|---|
| `id` | integer | não | PK |
| `name` | varchar(191) | não | |
| `slug` | varchar(191) | não | |
| `email` | varchar(191) | não | |
| `site` | varchar(191) | não | |
| `phone` | varchar(191) | não | |
| `image` | varchar(191) | sim | logotipo |
| `icon` | varchar(191) | sim | |
| `address` | varchar(500) | sim | |
| `locale` | varchar(500) | sim | URL do **embed do Google Maps** |
| `fornecedor_ativo` | boolean | sim | **seleciona** o fornecedor exibido |
| `whatsapp` | varchar(191) | sim | |
| `created_at` / `updated_at` | timestamp(0) | sim | |
| `deleted_at` | timestamp(0) | sim | `SoftDeletes` |

O model `Supplier` tem `$fillable` com **duas colunas inexistentes**:
`telefone` e `endereco` (herança de um esquema anterior; hoje os dados
estão em `phone` e `address`, expostos com esses alias na view SQL
`fornecedores`).

## 4. `configurations` (usada pelo sistema de tickets órfão)

O `SupportController@enviarEmail` lê três chaves:

| key | Uso |
|---|---|
| `email` | remetente (`$from` / `$from2`) |
| `email_suporte` | destinatário do e-mail de suporte (`$to`) |
| `titulo_site` | nome da prefeitura nos e-mails (`$prefecture`) |

A chave `email_suporte` é criada pelo
`v6/database/seeds/ConfigurationsTableSeeder.php` ("Neste e-mail será
recebido as solicitações de suporte.").

## 5. `modulos` e `resources`

| Item | Valor |
|---|---|
| `modulos` | id **9**, name "Suporte", slug `suporte`, `status = true` |
| `resources` | **NENHUMA LINHA** com slug `suporte` |
| `menu_orders` | **NENHUMA LINHA** para `suporte` |

Sem recurso, não há permissão concedível (`suporte.index`,
`suporte.create`, ...). A página viva só exige sessão.

## 6. Views SQL

**Nenhuma** é usada por este módulo. (A view `fornecedores` existe, mas é
consumida pelo módulo `fornecedores`.)

## 7. Relacionamentos

```
Support --hasOne--> User           (chave local 'users_id', id remoto)
Support --hasOne--> SupportCategory(chave local 'supports_categories_id', id remoto)
Supplier --(consulta direta)--> supplies
```

> As relações `hasOne` estão corretas porque a FK está na tabela
> `supports`; a semântica é "pertence a".

## 8. Migrations e seeds

| Item | Caminho | Efeito |
|---|---|---|
| Migration | `v6/database/migrations/2018_12_26_140420_create_supports_categories_table.php` | cria `supports_categories` |
| Migration | `v6/database/migrations/2018_12_26_140430_create_supports_table.php` | cria `supports` com as FKs |
| Seed | `v6/database/seeds/SupportCategorySeeder.php` | 4 categorias |

**As tabelas e o seed são idênticos na v5** — o módulo de tickets já
existia lá, igualmente órfão.

## 9. Observações de modelagem para a v7

1. **`supports.protocolo` deve ter índice único.** O protocolo é gerado
   por `max('id') + 1`, o que é frágil (condição de corrida) e pode
   colidir.
2. **O prefixo do protocolo depende da categoria** (`DU`, `ER`, `SU`,
   `EL`), o que torna o protocolo **não globalmente único** (duas
   categorias diferentes podem gerar o mesmo código com ids diferentes —
   na prática o id é global, então não colide, mas o formato é
   confuso).
3. **`supports_categories` precisa de `SoftDeletes`** no model, ou a
   coluna `deleted_at` deve ser removida.
4. **O módulo deveria ter um `slug`/`modulo_id`** caso o ticket passe a
   ser vinculado a um tipo de chamado.
5. Se a decisão for **fundir com o módulo `fornecedores`** (o que parece
   mais coerente com a implementação viva), as tabelas `supports` e
   `supports_categories` devem ser **removidas** — e o módulo `suporte`
   do registro de módulos, junto.