sgmp/README.md at main

6.6 KiB

Raw Permalink Blame History

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)

GESTOR cria uma Solicitacao (desligamento, admissão ou movimentação).
Solicitação começa em RASCUNHO.
GESTOR envia → status muda para AGUARDANDO_HEAD (quando há etapa de Head configurada) ou ENVIADA, conforme o tipo/regra.
HEAD (usuário com perfil principal ou extra HEAD) aprova/reprova solicitações em AGUARDANDO_HEAD, limitado aos gestores aos quais está vinculado (HeadGestor).
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.
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.

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.
Histórico e decisões sobre a relação Head–Gestor: 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:

Clonar o repositório:

git clone https://git.jurunense.com/felipe.araujo/sgmp.git
cd sgmp/SGMP_PROD

Criar e ativar o ambiente virtual:

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\\Scripts\\activate

Instalar dependências:

pip install --upgrade pip
pip install -r requirements.txt

Aplicar migrações:
```
python manage.py migrate
```
Criar usuário admin (opcional, para acesso a /admin/):
```
python manage.py createsuperuser
```
Rodar o servidor de desenvolvimento:
```
python manage.py runserver
```
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:

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)

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

6.6 KiB Raw Permalink Blame History Unescape Escape