title: Integração: Privacidade e LGPD/GDPR description: Conformidade com a Privacy API do Moodle e estratégias de anonimização e exclusão segura.

Privacidade (LGPD/GDPR)¶

O local_middag integra-se nativamente com o subsistema de Privacidade do Moodle, garantindo que as extensões e dados persistidos no framework respeitem os direitos de exportação e esquecimento (LGPD/GDPR).

O que é¶

É a implementação técnica dos mecanismos de conformidade exigidos pela plataforma Moodle. Como o framework armazena dados de usuários em tabelas próprias (EAV, Auditoria, Jobs), ele precisa oferecer uma interface que permita ao Moodle solicitar: 1. Exportação: Quais dados deste usuário estão no MIDDAG? 2. Exclusão/Anonimização: Remova ou oculte a identidade deste usuário do sistema.

No código, essa integração ocorre através do arquivo classes/privacy/provider.php, que herda das interfaces obrigatórias do Moodle core.

Por que existe¶

O Moodle exige que cada plugin declare sua política de dados. Se um plugin armazena dados de usuário e não implementa a API de Privacidade: * O sistema fica em não-conformidade legal. * O Moodle Report de Privacidade mostrará erros de segurança. * O usuário não conseguirá baixar seus dados de forma centralizada pelo perfil.

Além disso, deletar dados de auditoria e revisões em larga escala é uma operação sensível de performance que exige uma estratégia de infraestrutura específica.

Arquitetura da Solução¶

Para manter o desacoplamento e a performance em grandes volumes de dados, o framework utiliza um design híbrido:

Provider Estático (Fronteira): O Moodle chama métodos estáticos no provider.php. Este arquivo apenas inicializa o Kernel (middag::init()) e delega o trabalho para o container de DI.
Privacy Repository (Infraestrutura): Uma classe especializada em persistência de conformidade que executa deleções e atualizações em massa no SQL direto.
Anonimização de Auditoria: Para não quebrar a integridade estrutural e histórica da trilha de auditoria, o framework prefere a anonimização à exclusão total para logs de sistema (alterando o userid para zero e a mensagem para ANONYMIZED).

Decisões de design¶

Performance Massiva: Não usamos os Models hidratados (Domain) para deletar registros de LGPD. A exclusão de centenas de milhares de linhas de auditoria seria inviável via objetos individuais. Utilizamos queries otimizadas no Privacy Repository.
Acesso Restrito ao Contexto: A Privacy API do Moodle depende fortemente de objetos de context (curso, categoria, sistema). O repositório de privacidade é o único local do framework autorizado a lidar com esses objetos de forma acoplada ao Moodle para fins de exportação e deleção.
Fidelidade Crítica: Ao exportar dados, o framework utiliza o Writer do Moodle para gerar um JSON estruturado seguindo o padrão da plataforma, garantindo que o usuário receba uma leitura legível de suas informações.

O que não é¶

Não é uma Substituição da Lei: A ferramenta técnica facilita a conformidade, mas a política de retenção de dados (por quanto tempo guardar) deve ser configurada pelo administrador do Moodle.
Não Afeta Dados de Terceiros: O framework deleta/anonimiza apenas o que está nas tabelas middag_*. Se sua extension criar tabelas SQL fora do padrão, você deve estender seu próprio provider de privacidade.
Não é Opcional: Todo TYPE de Item que armazena referências a usuários deve ser mapeado na política de privacidade do framework.

Perspectiva para builders de extensions¶

Para que sua extension esteja em conformidade: 1. Use o Repositorio de Itens Padrão: O framework já cuida da auditoria e dos metadados dos itens criados por extensions. 2. Declare Metadados Sensíveis: Se o seu metadado no Item guarda algo sensível (como telefone ou CPF), informe ao framework para que ele saiba que aquele campo deve ser incluído na exportação de privacidade. 3. Não armazene dados de usuário em arquivos soltos: Prefira o sistema de arquivos do Moodle (File API), que também é coberto pela Privacy API.

Exemplo ilustrativo¶

O fluxo de uma exclusão de dados por LGPD:

// No Moodle Provider (estático)
public static function delete_data_for_user(approved_contextlist $contextlist) {
    // 1. Inicializa o framework e obtém o repositório de DI
    $repository = middag::get(privacy_repository_interface::class);

    // 2. Executa a deleção/anonimização otimizada
    $repository->delete_user_data($contextlist);
}

A regra interna do repositório garante que o campo userid em todas as tabelas middag_* seja limpo nos contextos solicitados.