portal_publico/README.md

4.8 KiB

Portal De Paula

Portal interno da De Paula Contadores — Python 3.13 + Django 6.0 + Django REST Framework + PostgreSQL 14, servindo tanto a API (/api/...) quanto o frontend HTML/CSS/JS (mesma origem). Portal/ é o próprio projeto Django (manage.py na raiz), organizado no padrão convencional de um projeto Django.

Como rodar localmente

cd Portal
python -m venv .venv
.venv\Scripts\activate          # Windows
pip install -r requirements.txt

Configurar as variáveis de ambiente do Postgres 14 antes de migrar — config/settings.py lê DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, DB_PORT do .env (já existe na raiz de Portal/):

python manage.py makemigrations portal_api
python manage.py migrate
python manage.py runserver

Abrir http://localhost:8000/ — o Django serve index.html e as demais páginas do frontend diretamente, sem precisar de um segundo servidor pro frontend.

Não rodar python manage.py seed_portal neste ambiente. O Portal já está em produção e o banco apontado pelo .env é o banco real, não uma cópia de desenvolvimento. O comando ressincroniza incondicionalmente permissoes/ativo/gerencia_permissoes dos 8 perfis de código fixo a partir de catalogo.py a cada execução — rodá-lo reverteria, sem nenhum aviso, qualquer permissão que um admin tenha customizado pela tela de Perfis de Acesso. O comando existe só para criar um ambiente novo/vazio do zero. Ver CLAUDE.md → "Como rodar / testar localmente" para o detalhamento.

As contas de usuário (incluindo gabriel e bruno) já existem no banco de produção, com senhas e perfis mantidos pelos próprios usuários pelas telas de Perfis de Acesso/Usuários. Num ambiente novo criado do zero, seed_portal cria gabriel (perfil "Inovação", acesso total) e bruno (sem perfil vinculado, para testar o estado "sem acesso").

Não há suíte de testes, lint ou build configurados neste projeto.

Mapa das aplicações

Aplicação Seção do menu Documentação
Principal (favoritos, widgets) Principal Favoritos, Calendário Individual e Widgets
Calendário Individual Calendário docs/calendario-individual/
Links & Ferramentas / Acessos Gerais Links & Ferramentas docs/links-ferramentas-acessos-gerais/
Ramais Ramais docs/ramais/
Solicitações Solicitações docs/solicitacoes/
Perfis de Acesso / Usuários Administração docs/perfis-usuarios/
Importação de Plano de Saúde Utilitários portal_api/planos_saude/
Importação de Plano de Saúde - De Paula (mesma ferramenta, para o plano dos próprios colaboradores) Utilitários portal_api/planos_saude/
Conciliação de Fornecedores Utilitários portal_api/conciliacao_fornecedores/
Simulação de Custo de Contratação Geradoc portal_api/custo_contratacao/
Indicador de Desempenho Geradoc portal_api/indicadores/
Não Conformidades Relatórios > Qualidade portal_api/nao_conformidades/
Relatório Contábil Relatórios > Contabilidade portal_api/dashboard_contabil/
Temas Sazonais (marca P.I.D. sazonal, hoje só Halloween) — (recurso visual, não é item de menu) docs/temas-sazonais/
Identidade visual (logos, marca P.I.D. na UI, animações, intro pós-login) — (camada transversal, não é item de menu) docs/identidade-visual/

Cada pasta acima tem um README.md (o que a aplicação faz, estado atual) e um CHANGELOG.md (histórico rodada a rodada, extraído de plano.md). As 5 aplicações com pacote Python próprio também têm um CLAUDE.md com o detalhamento técnico completo, carregado automaticamente pelo Claude Code; as demais têm esse detalhe no arquivo dentro da própria pasta em docs/.

Documentação transversal

  • CLAUDE.md — arquitetura geral do Portal (estrutura de pastas, modelo de permissões, API, CSS, animações). Carregado automaticamente pelo Claude Code.
  • plano.md — histórico de decisões estruturais/transversais (rodadas que mudaram mais de uma aplicação ao mesmo tempo, migração pra Django, modelo de permissões em si, identidade visual). Histórico específico de cada aplicação vive no CHANGELOG.md dela.