Documenta arquitetura atual e ajustes de perfis/head
This commit is contained in:
parent
e34e85f382
commit
542b9d03ca
|
|
@ -0,0 +1,176 @@
|
|||
## SGMP_PROD – Sistema de Gestão de Movimentações de Pessoas
|
||||
|
||||
### Visão geral
|
||||
|
||||
O **SGMP_PROD** é um sistema interno para gestão de processos de pessoas, hoje focado em:
|
||||
|
||||
- Desligamentos
|
||||
- Admissões (substituição e aumento de quadro)
|
||||
- Movimentações internas
|
||||
|
||||
Cada processo é representado por uma `Solicitacao` que percorre um fluxo controlado de aprovação, com rastreabilidade completa (status, aprovações, pareceres técnicos e anexos).
|
||||
|
||||
O projeto em produção é um monólito **Django** com renderização server-side e uso de **Tailwind CSS** para o layout das telas principais.
|
||||
|
||||
---
|
||||
|
||||
### Stack técnica
|
||||
|
||||
- **Linguagem**: Python 3.9
|
||||
- **Framework web**: Django 4.2
|
||||
- **Banco de dados aplicação**: SQLite (desenvolvimento) / compatível com outros bancos suportados pelo Django
|
||||
- **Integrações externas**:
|
||||
- **TOTVS RM (SQL Server)** – dados de colaboradores, cargos, seções, coligadas/filiais.
|
||||
- **Winthor (Oracle)** – autenticação e dados básicos de usuários.
|
||||
- **Frontend**:
|
||||
- Templates Django
|
||||
- Tailwind CSS via CDN (`base.html` e `dashboard.html`)
|
||||
- JavaScript vanilla para interações pontuais (modal de aprovação, filtros, expansão de linhas).
|
||||
- **Empacotamento / Deploy**:
|
||||
- Docker (`Dockerfile` e `entrypoint.sh`)
|
||||
- Servidor de aplicação: `gunicorn`
|
||||
|
||||
Principal app Django:
|
||||
|
||||
- `solicitacoes/` – contém:
|
||||
- `models.py`: modelos de domínio (`UsuarioSistema`, `UsuarioPerfilExtra`, `HeadGestor`, `PessoaRM`, `Solicitacao`, `Desligamento`, `AdmissaoSubstituicao`, `AdmissaoAumentoQuadro`, `Movimentacao`, `Aprovacao`, `Parecer`, enums de status/etapas).
|
||||
- `services.py`: regras de negócio transacionais (envio de solicitação, aprovação por Head/Diretoria, registro de parecer, etc.).
|
||||
- `views.py`: orquestração HTTP, dashboard, criação de solicitações, decisão, parecer, gerenciamento de permissões.
|
||||
- `templates/`: telas do dashboard, detalhe da solicitação e formulários.
|
||||
|
||||
---
|
||||
|
||||
### Fluxo de aprovação (resumo)
|
||||
|
||||
1. **GESTOR** cria uma `Solicitacao` (desligamento, admissão ou movimentação).
|
||||
2. Solicitação começa em **`RASCUNHO`**.
|
||||
3. GESTOR envia → status muda para **`AGUARDANDO_HEAD`** (quando há etapa de Head configurada) ou **`ENVIADA`**, conforme o tipo/regra.
|
||||
4. **HEAD** (usuário com perfil principal ou extra `HEAD`) aprova/reprova solicitações em `AGUARDANDO_HEAD`, limitado aos gestores aos quais está vinculado (`HeadGestor`).
|
||||
5. Após a etapa de Head, a solicitação segue para **`ENVIADA`**:
|
||||
- **GG** e **CONTROLADORIA** registram **pareceres técnicos** (`Parecer`) – não mudam o status diretamente.
|
||||
- Quando há parecer de GG e de Controladoria, o status avança para **`AGUARDANDO_DIRETORIA`**.
|
||||
6. **DIRETORIA** aprova ou reprova solicitações em `AGUARDANDO_DIRETORIA`:
|
||||
- Aprovada → **`FINALIZADA`**
|
||||
- Reprovada em qualquer etapa → **`REPROVADA`**
|
||||
|
||||
Regras principais:
|
||||
|
||||
- `Solicitacao.etapa_atual()` mapeia o status para a etapa de aprovação.
|
||||
- `Solicitacao.pode_aprovar(usuario)` centraliza a regra de quem pode aprovar na etapa atual (HEAD ou DIRETORIA, considerando perfis extras).
|
||||
- `Solicitacao.pode_dar_parecer(usuario)` define se GG / Controladoria podem registrar parecer na etapa `ENVIADA`.
|
||||
|
||||
Mais detalhes de arquitetura estão em [`ARQUITETURA_APROVACAO.md`](./ARQUITETURA_APROVACAO.md).
|
||||
|
||||
---
|
||||
|
||||
### Perfis, multi-perfis e relação Head–Gestor
|
||||
|
||||
- `UsuarioSistema` possui:
|
||||
- `perfil` – **perfil principal** (GESTOR, HEAD, GG, CONTROLADORIA, DIRETORIA).
|
||||
- `UsuarioPerfilExtra` – tabela de **perfis adicionais** (multi-perfis).
|
||||
- Métodos:
|
||||
- `tem_perfil(perfil)` – verifica se o usuário possui o perfil principal ou extra.
|
||||
- `perfis_ativos()` – lista todos os perfis do usuário (principal + extras).
|
||||
|
||||
- `HeadGestor` modela a relação **Head → Gestores**:
|
||||
- Campos: `head`, `gestor` (FK para `UsuarioSistema`).
|
||||
- Cada Head só vê/aprova solicitações de gestores vinculados nessa tabela.
|
||||
- A tela `/permissoes/` permite configurar, manualmente, quais gestores cada Head lidera.
|
||||
|
||||
Documentação detalhada de login, perfis e permissões: [`README_PERMISSOES.md`](./README_PERMISSOES.md).
|
||||
Histórico e decisões sobre a relação Head–Gestor: [`docs/head_relacao_gestor_investigacao.md`](./docs/head_relacao_gestor_investigacao.md).
|
||||
|
||||
---
|
||||
|
||||
### Como rodar localmente (sem Docker)
|
||||
|
||||
Pré-requisitos:
|
||||
|
||||
- Python 3.9
|
||||
- Acesso opcional aos bancos RM/Winthor (para full integração); sem eles, é possível rodar com dados mínimos locais.
|
||||
|
||||
Passos:
|
||||
|
||||
1. Clonar o repositório:
|
||||
```bash
|
||||
git clone https://git.jurunense.com/felipe.araujo/sgmp.git
|
||||
cd sgmp/SGMP_PROD
|
||||
```
|
||||
|
||||
2. Criar e ativar o ambiente virtual:
|
||||
```bash
|
||||
python -m venv .venv
|
||||
source .venv/bin/activate # Windows: .venv\\Scripts\\activate
|
||||
```
|
||||
|
||||
3. Instalar dependências:
|
||||
```bash
|
||||
pip install --upgrade pip
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
4. Aplicar migrações:
|
||||
```bash
|
||||
python manage.py migrate
|
||||
```
|
||||
|
||||
5. Criar usuário admin (opcional, para acesso a `/admin/`):
|
||||
```bash
|
||||
python manage.py createsuperuser
|
||||
```
|
||||
|
||||
6. Rodar o servidor de desenvolvimento:
|
||||
```bash
|
||||
python manage.py runserver
|
||||
```
|
||||
|
||||
7. Acessar:
|
||||
- Página de login: `http://localhost:8000/login/`
|
||||
- Dashboard: `http://localhost:8000/`
|
||||
- Admin Django: `http://localhost:8000/admin/`
|
||||
|
||||
> Observação: em desenvolvimento, integrações com RM/Winthor podem exigir configuração de variáveis de ambiente (host, porta, usuário, senha, etc.) conforme `SQLSERVER_CONFIG` e credenciais Oracle definidas no projeto.
|
||||
|
||||
---
|
||||
|
||||
### Como rodar com Docker
|
||||
|
||||
O projeto possui um `Dockerfile` voltado para produção (`gunicorn`), incluindo instalação do Oracle Instant Client para integração com Winthor.
|
||||
|
||||
Exemplo simples de build e run:
|
||||
|
||||
```bash
|
||||
cd SGMP_PROD
|
||||
|
||||
docker build -t sgmp_prod .
|
||||
|
||||
docker run --rm -p 8000:8000 \
|
||||
--env-file .env \\
|
||||
sgmp_prod
|
||||
```
|
||||
|
||||
O `entrypoint.sh` executa migrações e `collectstatic` antes de iniciar o `gunicorn`.
|
||||
|
||||
---
|
||||
|
||||
### Estrutura de diretórios (resumo)
|
||||
|
||||
```text
|
||||
SGMP_PROD/
|
||||
config/ # settings Django, urls, wsgi
|
||||
solicitacoes/ # app principal de domínio
|
||||
models.py # modelos de domínio
|
||||
services.py # regras de negócio
|
||||
views.py # views / endpoints
|
||||
templates/ # templates HTML (base, dashboard, solicitação_detalhe, formulários)
|
||||
migrations/ # migrations do Django
|
||||
templates/ # templates globais (base.html, dashboard.html, etc.)
|
||||
static/ # assets estáticos de desenvolvimento (se houver)
|
||||
ARQUITETURA_APROVACAO.md
|
||||
README_PERMISSOES.md
|
||||
docs/head_relacao_gestor_investigacao.md
|
||||
Dockerfile
|
||||
entrypoint.sh
|
||||
requirements.txt
|
||||
```
|
||||
|
||||
Loading…
Reference in New Issue