01. DADOS GERAIS
Produto: | Solucoes_totvs_parceirosexptotvs |
---|
|
|
---|
Linha de Produto: | |
---|
Segmento: | |
---|
Módulo: | Modulos_framework |
---|
ModulosFramework | Framework (Linha Logix) - LGPD (Lei Geral de Proteção de Dados) |
---|
|
|
---|
Função: | Consulta Mapeamento de Dados Protegidos por Vínculo do Titular - LOG10003 |
---|
País: | Brasil |
---|
Ticket: |
|
---|
Requisito/Story/Issue (informe o requisito relacionado) : | DFWKLOGIX-74 |
---|
02. SITUAÇÃO/REQUISITO
Atualmente na tabela LOG_PRIVATE_MAPPING_ATTRIBUTE o campo QUERY_ATTRIBUTE fica com o conteúdo repetido para a mesma tabela e vínculo, pois o layout da tabela permite cadastrar query por coluna, que faz parte da chave, no entanto a pesquisa é feita por tabela e identificador e não por coluna. Este item onera o tamanho de banco desnecessariamente.
Outro ponto é se uma tabela tiver apenas um campo pessoal cadastrado, se torna impossível cadastrar mais de uma query de filtro de pesquisa por identificadores diferentes.
03. SOLUÇÃO
Permitir registrar instruções SQL de consulta de dados protegidos de uma tabela por Tipo de Informação (CPF, RG, E-MAIL, etc) e não por coluna da tabela, para que seja possível registrar mais de uma instrução de consulta para uma mesma tabela, tendo esta uma única coluna registrada no controle de campos protegidos ou mais.
A instrução de consulta de uma tabela não tem ligação especificamente com uma coluna que está registrada no controle de campos protegidos, mas sim ao Tipo de Informação que será utilizado para busca do dado na tabela.
Exemplo:
Para pesquisa de dados na tabela FUNCIONARIO deverá ser possível consultar pelos seguintes tipos de informação:
- Pelo número do CPF
- Pelo e-mail
- Pelo número do título de eleitor
- Pelo número de CNH
Neste caso deve permitir registrar quatro instruções de consulta para a mesma tabela FUNCIONARIO, sendo uma consulta única para cada Tipo de Informação (CPF, E-MAIL, TITULO DE ELEITOR e CNH)
03. SOLUÇÃO
A tabela LOG_MAPPING_ATTRIBUTE foi eliminada pois sua funcionalidade foi assumida pela tabela LOG_PRIVATE_ALLOWS_ANONYMIZE, que por sua vez foi renomeada para LOG_PRIVATE_MAPPING, pois agora passou a armazenar todo o mapeamento de campos por Vínculo de Titular para uma tabela e também a condição para evitar a anonimização de dados de acordo com a classificação de um dado.
Em contrapartida, foi criada uma nova tabela chamada LOG_PRIVATE_MAPPING_TABLE que passou a controlar o mapeamento das instruções de consulta das tabelas por Vínculo do Titular.
O leiaute do programa "Mapeamento de Campos por Vínculo do Titular" (LOG10003) foi ajustado para faciltar a interpretação dos dados cadastrados e também para refletir as alterações das tabelas do banco de dados que foram criadas e alteradas..Retirado o campo QUERY_ATTRIBUTE da tabela LOG_PRIVATE_MAPPING_ATTRIBUTE;
Criada nova tabela: LOG_PRIVATE_MAPPING_TABLE, campos: Mapping_type, Table_name, Document_type, Query_filter;
A nova tabela foi carregada baseada na tabela LOG_PRIVATE_MAPPING_ATTRIBUTE, filtrando por Query_attribute únicos e por Document_type.
Adaptado LOG10003 para nova estrutura de tabelas, ficando com o layout abaixo:
Image Modified
04. DEMAIS INFORMAÇÕES
Não se aplica.
Card documentos |
---|
Informacao | Disponível a partir do pacote oficial 12.1.2205 ou Framework Fix 12.1.34.(fix01) |
---|
Titulo | IMPORTANTE! |
---|
|
05. ASSUNTOS RELACIONADOS
...