Sistema de Gestão de features para o EduMigSoft.

O sistema agora implementa um modelo robusto de autorização em dois níveis:

1. Papéis Globais - UserRole expandido com novo papel manager
2. Papéis por Feature - Controle de acesso granular para projetos, finanças, tarefas, etc.

Cada feature pode ter seus próprios membros com papéis independentes (owner, admin, manager, member, viewer), permitindo que diferentes usuários tenham diferentes níveis de acesso em diferentes projetos.

Exemplo de implementação disponível: project_user_role em packages/auth/auth_server

📚 Documentação completa: Auth Server README

Legenda: 🟢 Ativo | 🟡 Em desenvolvimento | 🔴 Planejado

# EMS Server ./scripts/build-local.sh ems # SMS Server ./scripts/build-local.sh sms

export GITHUB_TOKEN=ghp_XXXXXXXXXXXXXXXXXXXX ./scripts/push-to-ghcr.sh ems

Para documentação completa, veja: servers/OPERATIONS.md

Features da ideia inicial:

• App em Flutter
• Server em Dart/Shelf
• Gestão de Users
• Gestão de Aura (Tarefas)
• Gestão de Projects (com tarefas e financeiro do projeto, não utilizará a features de financeiro)
• Gestão de Finance (com receita e despesas)

O sistema possui um fluxo completo de autenticação e gestão de usuários, dividido em microsserviços e pacotes modularizados.

• Auth Server/Client: Responsável por login, registro, refresh token (com rotação), e recuperação de senha. Utiliza JWT (JSON Web Tokens).
• User Server/Client: Responsável pela gestão de dados do usuário (perfil, atualizações).

O acesso às funcionalidades é feito através do AuthService e UserClient configurados via injeção de dependência via GetIt.

// 1. Login final result = await authService.login(LoginRequest( email: 'user@example.com', password: 'password123', )); if (result case Success(value: final user)) { print('Bem-vindo, ${user.name}!'); } else if (result case Failure(error: final e)) { print('Erro ao logar: $e'); } // 2. Verificar Sessão (Automático na inicialização) // O AuthService tenta usar o refresh token armazenado para restaurar a sessão final isAuthenticated = await authService.isAuthenticated(); // 3. Logout await authService.logout();

// Buscar dados atualizados do usuário logado final result = await userClient.getMe(); if (result case Success(value: final userDetails)) { print('Email: ${userDetails.email}'); print('Role: ${userDetails.role}'); }

Abaixo estão os principais endpoints disponíveis na API:

O sistema implementa RBAC (Role-Based Access Control) em dois níveis:

• Owner (4) - Proprietário do sistema, acesso total
• Admin (3) - Administrador global, bypassa verificações de features
• Manager (2) - Gerente com permissões limitadas
• User (1) - Usuário comum (padrão)

Cada feature (projetos, finanças, tarefas) possui controle de acesso independente:

• Owner (5) - Proprietário da feature
• Admin (4) - Administrador da feature
• Manager (3) - Gerente (pode adicionar/remover membros)
• Member (2) - Membro contribuidor
• Viewer (1) - Visualizador (somente leitura)

Importante: Usuários com papel global admin ou owner têm acesso irrestrito a todas as features.

• Autenticação: Header Authorization: Bearer <token>
• AuthMiddleware: Valida JWT e popula AuthContext
• FeatureRoleMiddleware: Verifica papel específico em features

// Verificar papel global if (user.role.isAdmin) { // Acesso administrativo global } // Proteger rota com papel de feature router.post( '/projects/<projectId>/tasks', Pipeline() .addMiddleware(authMiddleware.protect()) .addMiddleware(featureRoleMiddleware.requireFeatureRole( FeatureUserRole.member, // Papel mínimo necessário (req) => req.params['projectId']!, )) .addHandler(_createTask), );

Cada feature (projetos, finanças, tarefas) mantém sua própria tabela de papéis, garantindo:

• Isolamento: Papéis de uma feature não interferem em outras
• Escalabilidade: Fácil adicionar novas features com controle de acesso
• Flexibilidade: Cada usuário pode ter diferentes papéis em diferentes contextos

Implementação de referência: Veja ProjectUserRoleRepository, ProjectUserRoleService e ProjectUserRoleRoutes em packages/auth/auth_server como exemplo completo para criar novas features.

A estrutura do projeto reflete a arquitetura multi-sistema:

ems_system/ ├── apps/ # Aplicativos Flutter │ ├── ems/ # Aplicativos EMS │ │ ├── app_v1/ # App principal EMS (produção) │ │ └── app_design_draft/ # Rascunhos e experimentos de design │ └── sms/ # Futuro: School Management System apps │ ├── servers/ # Servidores Dart/Shelf │ ├── ems/ # Servidores EMS │ │ └── server_v1/ # API principal EMS │ └── sms/ # Futuro: SMS server │ ├── packages/ # Features compartilhadas entre sistemas │ ├── core/ # Base do sistema │ │ ├── core_shared/ # Pure Dart - Domínio e utilitários │ │ ├── core_server/ # Shelf/Drift infrastructure │ │ ├── core_client/ # HTTP/Dio client │ │ └── core_ui/ # Flutter widgets base │ │ │ ├── auth/ # Autenticação e autorização │ │ ├── auth_shared/ # Modelos de domínio │ │ ├── auth_server/ # Backend (JWT, RBAC) │ │ ├── auth_client/ # Cliente HTTP │ │ └── auth_ui/ # UI de autenticação │ │ │ ├── user/ # Gestão de usuários │ │ ├── user_shared/ # Modelos de usuário │ │ ├── user_server/ # CRUD de usuários │ │ ├── user_client/ # Cliente HTTP │ │ └── user_ui/ # UI de perfil/usuários │ │ │ ├── design_system/ # Sistema de design │ │ ├── design_system_shared/ │ │ └── design_system_ui/ │ │ │ ├── images/ # Gestão de imagens │ │ └── images_ui/ │ │ │ ├── localizations/ # Internacionalização │ │ ├── localizations_shared/ │ │ ├── localizations_server/ │ │ └── localizations_ui/ │ │ │ ├── open_api/ # Especificações OpenAPI │ │ ├── open_api_shared/ │ │ └── open_api_server/ │ │ │ └── {features}/ # Novas features seguem padrão: │ ├── {feature}_shared/ # Pure Dart models │ ├── {feature}_server/ # Backend implementation │ ├── {feature}_client/ # HTTP client │ └── {feature}_ui/ # Flutter UI │ ├── scripts/ # Scripts de automação ├── docs/ # Documentação adicional ├── README.md ├── CHANGELOG.md ├── LICENSE.md └── CONTRIBUTING.md ## 🆕 Novo objetivo e estrutura ### Objetivo O novo objetivo é utilizar o sistema EMS System como base para sistemas orientado por features e aplicativos (app e server) este tendo as features base do sistema compartilhados para que seja modular e escalável. Ambos aplicativos deverá ter seus proprios .env (variáveis de ambientes), databse independentes. Será compartilhado somente a base de códigos. Em relação a localização para evitar duplicidade e excesso de traduções sem necessidade em um aplicativo que não precisa, teremos: localization > para as traduções comuns, localization_ems > para o sistema EMS e assim para os demais sistemas. Em relaçao ao design_system, inicialmente seŕa compartilhado, mas futuramente, será feito estudos/expreiência para diferencia-los. O sistema deve ser capaz de gerenciar features diversas de forma eficiente, com funcionalidades como: 

• App
  • ems_app # aplicativo voltado para o sistema de gestão pessoal/empresarial
    • ems_app_v1
  • sms_app
    • sms_app_v1 # aplicativo voltado para o sistema de gestão School Manager System
• Server
  • ems_server
    • ems_server_v1 # servidor voltado para o sistema de gestão pessoal/empresarial
  • sms_server
    • sms_server_v1 # servidor voltado para o sistema de gestão School Manager System
• packages
  • core
    • core_shared
    • core_server
    • core_client
    • core_ui
  • design_system
    • design_system_shared
    • design_system_server
    • design_system_client
    • design_system_ui
  • images
    • images_shared
    • images_server
    • images_client
    • images_ui
  • localizations # traduções compartilhado entre os sistemas, cada sistema terá sua própria feature de traduções (localizations_ems, localizations_sms, etc)
    • localizations_shared
    • localizations_server
    • localizations_client
    • localizations_ui
  • open_api
    • open_api_shared
    • open_api_server
    • open_api_client
    • open_api_ui
  • {features} # exemplo de feature que poderá ser utilizada em qualquer um dos aplicativos
    • {feature}_shared
    • {feature}_server

Ideias de features:

• Gestão de tarefas # para o EMS e SMS
• Gestão de projetos # para o EMS e SMS
• Gestão de usuários # para o EMS e SMS
• Gestão de finanças # para o EMS e SMS
• Gestão de imagens # para o EMS e SMS
• Gestão de alunos # para o SMS
• Gestão de turmas # para o SMS
• Gestão de notas # para o SMS
• Gestão de professores # para o SMS
• Gestão de turmas # para o SMS

A idéia é aproveitar os conceitos e técnicas de códigos para ambas os sistemas e futuros, facilitando a manutenção e evolução conjunta.

Uma alteração nos pacotes base, afetará todos os sistemas, o que pode ser um problema em caso de mudanças drásticas na arquitetura ou nas tecnologias utilizadas.

Mudanças nas bases devem ser feitas em branches separadas e testadas exaustivamente antes de serem mescladas nas bases principais.