a1a4d0a5d1
- Cria tabela 'agenda' com FKs normalizadas e colunas específicas de evento - Gera operações CRUD via SQLC para Agenda - Implementa Service e Handler da Agenda - Adiciona cálculo automático de 'status_profissionais' (OK/FALTA/ERRO) baseado na contagem de faltantes - Registra rotas da Agenda em /api/agenda - Atualiza documentação Swagger - Corrige caminhos de importação e tipagem UUID no novo serviço
84 lines
4.5 KiB
Markdown
84 lines
4.5 KiB
Markdown
# Documentação do Projeto Photum - Sessão de Desenvolvimento
|
|
|
|
Esta documentação resume todo o trabalho realizado durante a sessão atual de desenvolvimento, focada na implementação do Backend e ajustes no Frontend para o sistema Photum.
|
|
|
|
## 1. Visão Geral
|
|
O objetivo principal foi fortalecer o backend em Go, implementar autenticação segura, e criar as estruturas para gerenciamento de FOT (Formandos, Organização, Turma) e Agenda de Eventos.
|
|
|
|
## 2. Implementações no Backend (Go + PostgreSQL)
|
|
|
|
### 2.1. Sistema de Autenticação e Usuários
|
|
- **JWT & Refresh Tokens**: Implementação de autenticação baseada em tokens JWT curta duração e Refresh Tokens seguros.
|
|
- **Hierarquia de Permissões (RBAC)**: Definição de roles padronizadas: ROLES Backend (Strings no Banco de Dados):
|
|
|
|
admin ⮕ Mapeado para SUPERADMIN
|
|
empresa ⮕ Mapeado para BUSINESS_OWNER
|
|
cliente ⮕ Mapeado para EVENT_OWNER
|
|
profissional ⮕ Mapeado para PHOTOGRAPHER
|
|
|
|
admin@photum.com -> SUPERADMIN
|
|
empresa@photum.com -> BUSINESS_OWNER
|
|
foto@photum.com -> PHOTOGRAPHER
|
|
- **Fluxo de Aprovação**:
|
|
- Usuários se registram com status `ativo=false`.
|
|
- Admin lista usuários pendentes (`/admin/users/pending`).
|
|
- Admin aprova e define a Role (`/admin/users/:id/approve` e `/admin/users/:id/role`).
|
|
- Bloqueio de login para usuários inativos.
|
|
- **Dados do Usuário**: Adição de campos `Nome`, `Telefone` e `Empresa` no registro e listagens.
|
|
|
|
### 2.2. Tabelas Auxiliares (CRUDs)
|
|
Criadas tabelas, Services e Handlers para as entidades básicas do sistema:
|
|
- `cursos`
|
|
- `empresas`
|
|
- `anos_formaturas`
|
|
- `tipos_eventos` (incluindo tabela de preços por função)
|
|
- `tipos_servicos`
|
|
- `funcoes_profissionais`
|
|
|
|
### 2.3. Módulo Cadastro FOT
|
|
Responsável por vincular Turmas a Empresas e Instituições.
|
|
- **Tabela**: `cadastro_fot` (Campos: `fot`, `empresa_id`, `curso_id`, `ano_formatura_id`, `instituicao`, `observacoes`, etc.).
|
|
- **Backend**:
|
|
- Endpoint `POST /api/cadastro-fot`: Criação com verificação de FOT duplicado.
|
|
- Endpoint `GET /api/cadastro-fot`: Listagem com _joins_ para trazer nomes de Empresa, Curso, etc.
|
|
- **Integração**: Conectado ao `CourseManagement.tsx` no frontend.
|
|
|
|
### 2.4. Módulo Agenda
|
|
Responsável pelo agendamento de eventos vinculados a um FOT.
|
|
- **Tabela**: `agenda` criada com uma estrutura normalizada, mas com campos específicos de evento.
|
|
- Vinculada a `cadastro_fot` via `fot_id`.
|
|
- Campos de dados do evento: `data_evento`, `local_evento`, `horario`, etc.
|
|
- Campos de quantitativos: `qtd_formandos`, `qtd_fotografos`, `qtd_recepcionistas`, etc.
|
|
- Campos de controle: `status_profissionais`, `foto_faltante`, `pre_venda`, etc.
|
|
- **Backend**:
|
|
- Arquivos gerados via SQLC (`internal/db/generated/agenda.sql.go`).
|
|
- Service (`internal/agenda/service.go`) e Handler (`internal/agenda/handler.go`) implementados.
|
|
- Rotas registradas em `cmd/api/main.go` sob `/api/agenda`.
|
|
|
|
### 2.5. Decisões Técnicas Backend
|
|
- **Framework**: Gin Gonic.
|
|
- **Database**: PostgreSQL com driver `pgx/v5`.
|
|
- **Geração de Código**: Utilização do `sqlc` para gerar código Go type-safe a partir de queries SQL puras.
|
|
- **Estrutura**: Padrão `internal/domain` (Service/Handler/Repository isolados).
|
|
|
|
## 3. Implementações no Frontend (React/Next.js)
|
|
|
|
### 3.1. Autenticação e Sessão
|
|
- **AuthContext**: Melhoria na persistência de sessão. O frontend valida o token ao carregar e mantêm o usuário logado.
|
|
- **Logout**: Implementada função de logout que chama o backend e limpa o estado local.
|
|
- **UserApproval**: Interface para aprovação de usuários pendentes, exibindo Nome, E-mail e Empresa.
|
|
|
|
### 3.2. Gerenciamento de FOT (`CourseManagement.tsx`)
|
|
- **Listagem**: Atualizada para consumir `/api/cadastro-fot` em vez de dados mockados.
|
|
- **Formulário de Criação (`FotForm.tsx`)**:
|
|
- Modal para criar novo FOT.
|
|
- Dropdowns (Selects) conectados dinamicamente às APIs `/api/empresas`, `/api/cursos`, `/api/anos-formaturas`.
|
|
- Validação e envio dos dados para o backend.
|
|
|
|
### 3.3. API Service
|
|
- **`apiService.ts`**: Centralização das chamadas HTTP. Adicionadas funções para buscar cursos, anos de formatura, criar FOT, etc.
|
|
|
|
## 4. Próximos Passos Sugeridos
|
|
1. **Frontend Agenda**: Criar a interface para visualizar e editar a Agenda (`Calendar` ou `List View`), consumindo os endpoints `/api/agenda` já criados.
|
|
2. **Validações Avançadas**: Implementar regras de negócio mais complexas no backend (ex: conflito de horários).
|
|
3. **Relatórios**: Gerar PDFs ou Excels baseados nos dados de FOT e Agenda.
|