Fala galera, tudo certo? Hoje o post é da Live #29 para você entender tudo de segurança de linha (RLS), de colunas e de página! Um material completíssimo para te ajudar no dia a dia.
Vamos mostrar vários exemplos de uso! Cada empresa tem uma regra específica de aplicação de segurança de informação, mas entendendo os conceitos apresentados nos exemplos você vai conseguir utilizar de base para solucionar seus problemas. Então, vem comigo!
Clique aqui para dominar o Power BI, e se tornar um profissional valioso para o mercado de trabalho.
RLS – Row Level Security
Row Level Security (RLS) quer dizer segurança a nível de linha e o objetivo é restringir as linhas que ficarão visíveis para certo usuário. A vantagem disso é ter apenas um único relatório e otimizar a manutenção! Então, você tem um único relatório que filtra os resultados apresentados pelo usuário que está visualizando.
As etapas do processo são as seguintes:
- Definir regras de acesso no Power BI Desktop
- Testar as regras criadas
- Publicação do relatório no Power BI Online
- Atribuir as regras de acesso aos usuários
- Compartilhar com os usuários
RLS Estático
Vamos olhar as tabelas que iremos trabalhar e o relacionamento entre elas? Então, lá em modelo:
Figura 1: Modelo com as tabelas e relacionamentos do relatório
No nosso cenário, temos 3 países (France, Germany e United Kingdom) e queremos restringir a informação para cada um deles, pois temos um gerente responsável para cada país. Então, quando o gerente da França (France) entrar no Power BI Online para ver o relatório ele vai ver somente as informações referente aquele país.
A visão geral (sem RLS aplicada) do relatório é a seguinte:
Figura 2: Visão geral do relatório
Criando as regras
As regras de acesso são criadas em Gerenciar funções:
Figura 3: Gerenciamento de regras
O gerenciamento que vamos fazer é chamado de estático, pois para cada filtro que iremos aplicar (France, Germany e United Kingdom) temos que criar uma regra.
Figura 4: Área para criar as funções
O primeiro filtro que vamos criar é para a França (País = France) e os outros são feitos de maneira análoga alterando o nome:
Figura 5: Criação de função para France
Figura 6: Atribuindo regra em DAX
Figura 7: Atribuindo regra em DAX
E da mesma forma criamos para Germany e United Kingdom:
Figura 8: Atribuindo as outras regras
Etapas: Em "Modelagem" selecionar "Gerenciar funções" → Selecionar "Criar" → Nomear a função → Selecionar a tabela dCliente → Selecionar "Adicionar Filtro" → Selecionar a coluna [País] → Atribuir o filtro DAX
Fórmulas DAX:[País] =
“France”
[País] =
“Germany”
[País] =
“United Kingdom”
Testando as regras
Tem uma ferramenta muito legal no Power BI Desktop que permite você visualizar seu relatório como um dos usuários das regras criadas! Então, antes de publicar não deixe de fazer o teste. Aqui iremos testar para o usuário visualizar a regra de France:
Figura : Alterando modo de exibição
Figura 9: Modo padrão (default) de exibição
Figura 10: Visualizando com a regra France aplicada
Figura 11: Resultado na página
Etapas: Em "Modelagem" selecionar "Exibir como" → Selecionar a função como você quer que seja apresentado o relatório
Publicação e atribuição de regras – Power BI Online
Teste, tá ok? Se sim, bora publicar o relatório no Power BI Online. Aqui não tem segredo é só fazer como está acostumado e selecionar o workspace correto:
Figura 12: Publicando relatório
Pode ser: grupo de segurança, lista de distribuição, e-mail específico
Isso não quer dizer que o relatório será compartilhado com as pessoas que estão na lista, mas que aquela regra de função vai estar atribuída aos usuários na lista!
Figura 13: Aplicação de segurança no PBI Online
Figura 14: Área de configuração
Figura 15: Atribuição de usuários
Etapas: 1. Em "Página inicial" selecionar "Publicar" → Escolher o workspace de publicação 2. No PBI Online em "Conjunto de dados + fluxo de dados" clicar nos 3 pontos → Selecionar "Segurança" → Atribuir o usuário/grupo/lista que pertencem aquela função
Feito a atribuição dos usuários, é importante conhecer também as formas de compartilhamento nas quais o RLS funciona:
- Compartilhar de forma individual
- Compartilhar por um app
- Incluir o usuário como Visualizador no Workspace
| Importante: Se você incluir o usuário como contribuidor, membro ou administrador no Workspace o RLS NÃO vai funcionar. |
| Importante: O RLS NÃO funciona em relatórios públicos!! Além disso, só funciona se tanto o usuário que for publicar e quanto o que for visualizar tiver licença PRO. |
| Importante: Para o Power BI Embedded as regras de desenvolvimento no Power BI Desktop são iguais, porém é necessário programação para a atribuição de regras. |
Figura 16: Compartilhamento de forma individual
Figura 17: Seleção de usuários ou grupo para compartilhamento
Figura 18: Criação de aplicativo
Figura 19: Inclusão de usuário no workspace
Figura 20: Seleção de usuários ou grupo para compartilham
RLS Dinâmico
O cenário para as o RLS dinâmico é diferente do primeiro. Imagine que ao invés de definir por País a regra será feita a partir da seguinte lista de usuários:
Figura 21: Lista de usuários
| Importante: A tabela de usuários tem que se manter atualizada, independente se for um banco de dados/tabela Excel, para poder ter os filtros corretos atribuídos aos relatórios! |
Nesse cenário cada usuário pode ter um ou mais clientes, porém cada cliente tem somente um usuário. Pode imaginar como se fosse um vendedor que tem uma carteira de clientes, porém cada cliente é atendido por um vendedor específico.
Nesse caso, temos uma relação da tabela dUsuario para a dCliente de 1 para Muitos. Lá em modelo, temos que criar a relação entre essas tabelas:
Figura 22: Relacionamento entre as tabelas
Para RLS Dinâmico, também temos que criar uma regra de filtro. Só que imagine se fizermos igual na estática. Para filtrar esses usuários teríamos que criar 9 filtros….e se fosse filtrar por cliente (360 regras) então, daí imagina o tempo que você ia gastar com isso. Vamos melhorar? Imagina que entre mais usuários ou clientes e você tivesse que atualizar suas regras cada vez que isso acontecesse. Inviável, né?
Vem comigo, que vou fazer de uma forma diferente! O controle será feito nas tabelas.
| Importante: No RLS dinâmico é necessário ter uma tabela de usuários (ex.: vendedores/funcionários de cada setor) com o e-mail que ele irá acessar o Power BI Online em uma das colunas. |
Esse controle é feito utilizando o e-mail do usuário que ele acessa o Power BI Online. Essa informação de e-mail que gera o filtro na tabela dCliente a partir da tabela dUsuario. Então, o filtro é propagado para a tabela fVendas e fMetas.
Opa, legal! Bastante teoria? Então, vamos colocar em prática para fixar:
Figura 23: Gerenciar funções
Figura 24: Criar nova função
Figura 25: Filtro por e-mail do usuário
Figura 26: Expressão sem edição
Figura 27: Expressão do filtro de e-mail
Fórmula DAX:[Email] =
USERNAME ()
Etapas: Em "Modelagem" selecionar "Gerenciar funções" → Selecionar "Criar" → Nomear a função → Selecionar a tabela dUsuario → Selecionar "Adicionar Filtro" → Selecionar a coluna [Email] → Atribuir o filtro DAX
A função USERNAME retorna o usuário que está logado no relatório. É exatamente o que precisamos, não?! Então, a partir dessa informação que geramos o filtro.
| Dica: Quando estamos logado no Power BI Desktop, a função USERNAME retorna o usuário logado na máquina e no Power BI Online ele retorna o e-mail de quem está no ambiente Online. |
Regra, criada! Qual o próximo passo? Publicar?? Não, né! Temos que testar! Vamos testar para o usuário user3@powerbiexperience.com:
Figura 28: Teste de exibição
Figura 29: Escolha de usuário
Figura 30: Resultado do Filtro
Etapas: Em "Modelagem" selecionar "Exibir como" → Preencher o usuário e selecionar a regra criada
Se formos em “Dados”, podemos ver os filtro aplicado nas tabelas:
Figura 31: Tabela dUsuario e dCliente (somente 35 linhas)
Legal, e como seria para o Diretor da empresa? Ele tem que ver tudo, né? Para esse tipo de caso usamos o artifício da regra de admin:
Figura 32: Filtro de admin
Como não tem nenhuma regra de filtro nessa função, quem estiver nesse grupo vai visualizar o relatório completo!
Relatório pronto, próximo passo publicar:
Figura 33: Publicação do relatório
| Importante: A partir do momento que você publicar um relatório com alguma regra de RLS, todos os usuários visualizadores precisam ser atribuídos à alguma regra! Caso contrário, o relatório aparecerá quebrado para esse usuário. |
O gerenciamento no Power BI Online é idêntico ao do RLS Estático!
E aí, o que achou? Vai te ajudar no dia a dia? Deixa nos comentários e continua que tem mais exemplos!
Dinâmico N-N com Relacionamentos
Aqui vamos ver o tão comentado relacionamento de muitos para muitos!
Nesse cenário cada usuário pode ter um ou mais clientes, e diferente do exemplo passado cada cliente também pode ter mais de um usuário relacionado. Pode imaginar como se fosse um vendedor de loja vende para vários clientes e se o cliente quiser também pode comprar com outro vendedor.
Esse é um caso clássico de Muitos para Muitos! Para fazer esse relacionamento vamos usar uma tabela de apoio. Esse tipo de tabela tem dois nomes na comunidade bridge table (tabela ponte) e factless fact table (tabela fato sem fato)! Eu particularmente prefiro a primeira Bridge Table.
Nossa bridge table, contém todas a relações de clientes com usuários:
Figura 34: Bridge Table (UsuarioCliente)
E ela tem 2 relacionamentos de um lado com a tabela dCliente e do outro dUsuario:
Figura 35: Relacionamentos da Bridge Table
O relacionamento da dUsuario para a UsuarioCliente (Bridge Table) é comum de 1 para Muitos. Já a do UsarioCliente (Bridge Table) com a dCliente é de Muitos para 1 porém em ambas as direções!
Figura 36: Relacionamento da Bridge Table com a dCliente
Etapas: 1. Criar o relacionamento entre a tabela dUsuario e UsuarioCliente (Bridge Table) pela coluna ID Usuario com direção única e cardinalidade Muitos para um (*:1) 2. Criar o relacionamento entre a tabela UsuarioCliente (Bridge Table) e dCliente pela coluna ID Cliente com direção ambas e cardinalidade Muitos para um (*:1). Ativar o filtro em ambos os sentidos!
Lembra aquela regra (RLS) que criamos em “Gerenciar funções”??! Então, é a mesma que usamos nesse tipo de caso! Aplicando a regra de USERNAME que é o usuário lá do Power BI Online. E agora, vamos publicar? Não!! Vamos fazer o teste para o usuário user5@powerbiexperience.com:
Figura 37: Teste de exibição
Figura 38: Escolha de usuário
Figura 39: Resultado do filtro
Etapas:
Em "Modelagem" selecionar "Exibir como" → Preencher o usuário e selecionar a regra criada
Opa, show de bola! Funcionou….agora sim, podemos publicar:
Figura 40: Publicação do relatório
E para esse tipo de RLS a parte de gerenciamento no Power BI Online também é idêntico ao estático!
Dinâmico N-N com DAX
O cenário é idêntico ao do exemplo ao anterior! Cada usuário pode ter um ou mais clientes, e cada cliente também pode ter mais de um usuário relacionado. Pode imaginar como se fosse um vendedor de loja vende para vários clientes e se o cliente quiser também pode comprar com outro vendedor.
Só que! Só que! Não vamos utilizar relacionamentos entre tabela para fazer o filtro….iremos fazer via DAX. Criaremos uma tabela virtual usando CALCULATETABLE e VALUES nas expressões dos filtros em “Gerenciar funções”:
Figura 41: Criação da nova RLS
Figura 42: Filtro para tabela dCliente
Fórmula DAX: [ID Cliente] IN CALCULATETABLE( VALUES( UsuarioCliente[ID Cliente] ), dUsuario[Email] = USERNAME() )
Etapas: Em "Modelagem" selecionar "Gerenciar funções" → Selecionar "Criar" → Nomear a função → Selecionar a tabela dCliente → Selecionar "Adicionar Filtro" → Atribuir o filtro DAX
Pronto! Bora publicar?Nãoooo…..vamos testar! Agora como o user7@powerbiexperience.com:
Figura 43: Escolha de usuário
Figura 44: Resultado do filtro
Etapas: Em "Modelagem" selecionar "Exibir como" → Preencher o usuário e selecionar a regra criada
| Importante: Em todos esses casos, o usuário está filtrando o cliente. Porém, ele vê todas as informações na tabela de vendas daquele cliente! Não eliminando as linhas de vendas para usuários diferentes, pois a tabela fVendas e dUsuario não estão relacionadas diretamente. |
Dinâmico N-N com Gerente
Nesse cenário, vamos supor que quando eu publicar o relatório no Power BI Online não podemos usar o artificio do admin (Lembra dele? Para os diretores que têm acesso a todas informações). Então, dentro do modelo no Power BI Desktop iremos solucionar esse problema.
Na tabela dUsuario, temos uma coluna a mais informando se aquele usuário é (valor = 1) ou não (valor = 0) gerente e terá acesso as informações:
Figura 45: Tabela dUsuario com a coluna extra
O modelo de base é o mesmo que utilizamos com a Bridge Table (UsuarioCliente):
Figura 46: Modelo de relacionamento com Bridge Table (UsuarioCliente)
No entanto, a regra de RLS nesse caso é diferente se o usuário tem o valor 1 (é gerente) ou não (então é zero e não é gerente). Então, com auxilio de variáveis e das funções LOOKUPVALUE e IF vamos montar a seguinte regra para a tabela dUsuario:
Figura 47: Criação da nova RLS
Figura 48: Filtro para tabela dUsuario
Fórmula DAX: VAR vUser = USERNAME() VAR vGerente = LOOKUPVALUE( dUsuario[Gerente], dUsuario[Email], vUser ) RETURN IF( vGerente = 0, dUsuario[Email] = vUser, TRUE() )
E agora o que fazemos? Testamos novamente…..agora para o user9@powerbiexperience.com (valor de gerente 0) e para o demo@powerbiexperience.com (valor de gerente 1, com acesso a todas informações):
Figura 49: Filtro e resultado para user9@powerbiexperience.com
Figura 50: Filtro e resultado para demo@powerbiexperience.com
Etapas: Em "Modelagem" selecionar "Exibir como" → Preencher o usuário e selecionar a regra criada
Com o teste realizado é publicar o relatório e aplicar as regras de segurança no Power BI Online.
Dinâmico N-N com Hierarquia Simples
Esse é o cenário mais padrão que encontramos no mercado onde temos uma hierarquia de funcionário e seu líder. Então, na mesma tabela temos os usuários e os respectivos e-mails e também os líderes (gerentes) com seus respectivos e-mails:
Figura 51: Tabela de usuários com seus líderes
Nesse tipo de caso temos que ter 2 regras em gerenciar funções. O filtro para o usuário será o e-mail do usuário filtrando a coluna [Email] e o filtro do gerente será o e-mail do gerente filtrando a coluna [ Email Gerente]:
Figura 52: RLS para Usuario
Figura 53: Filtro aplicado
Fórmula DAX:[Email] =
USERNAME ()
Etapas: Em "Modelagem" selecionar "Gerenciar funções" → Selecionar "Criar" → Nomear a função → Selecionar a tabela dUsuario → Selecionar "Adicionar Filtro" → Selecionar coluna [Email] → Atribuir o filtro DAX
Figura 54: RLS para Gerente
Figura 55: Filtro aplicado
Fórmula DAX:[Email Gerente] =
USERNAME ()
Etapas: Em "Modelagem" selecionar "Gerenciar funções" → Selecionar "Criar" → Nomear a função → Selecionar a tabela dUsuario → Selecionar "Adicionar Filtro" → Selecionar coluna [Email Gerente] → Atribuir o filtro DAX
E agora, o que fazemos? Issooo…..vamos testar! Vamos testar para o John e ver como fica o resultado?
Figura 56: Resultado de exibição para John
Etapas: Em "Modelagem" selecionar "Exibir como" → Preencher o usuário e selecionar a regra criada
| Dica: Se acima do gerente tivesse um diretor, por exemplo, a lógica seria bem parecida. É só criar mais uma função dentro de “Gerenciar funções” e filtrar a coluna do [Email Diretor] como fizemos para o gerente! Assim teríamos 3 regras. |
| Importante: Aqui tem um ponto importante para atribuir as listas corretas de e-mail em cada regra lá no Power BI Online! Os e-mails de gerentes na RLS Gerente e de usuários em RLS Usuario |
Data Masking
Nesse cenário, não vamos fazer um RLS exatamente. A gente vai trabalhar mascarando os dados com medidas em DAX.
Máscara 1
Imagine que um usuário vai estar logado e vai conseguir ver as suas informações e também de todos os outros gerentes. Porém, não consegue visualizar a informação de outros usuários com o nível sem ser de gerente.
Parece um pouco confuso, mas o resultado esperado seria esse para a visualização como User4:
Figura 57: Resultado de exibição para User4
Isso não é feito com relacionamento e regras de função, vamos fazer nossa medida:
Total Vendas Masked v1 =VAR vUsuarioContexto =
SELECTEDVALUE ( dUsuario[Email] ) // atribui o valor do email do usuário no contexto do visual para a variável
VAR vUsuarioLogado =
USERNAME () // atribui o valor do email do usuario logado para a variável
VAR vReturn =
SWITCH (
TRUE ();
HASONEVALUE ( dUsuario[ID Usuario] )
&& vUsuarioContexto <> vUsuarioLogado; “*”;
// verifica se é só um valor (para gerentes tem mais de uma valor) e se as variáveis são diferentes, se sim retorna “*” se não retorna o valor da medida de vendas
[Total Vendas]
)
RETURN
IF ( [Total Vendas]; vReturn )
Com a medida criada é só colocar no visual de tabela e utilizar o “Exibir como” para testar a visualização para cada usuário.
Máscara 2
No último caso, fizemos a medida para o contexto de usuário. E se olharmos o resultado com uma tabela de clientes para o mesmo User4:
Figura 58: Tabela com o contexto de clientes
Olhando dessa perspectiva, nenhum filtro é aplicado pois a condição que colocamos na medida da máscara 1 era só para usuário. Então, vamos criar uma nova medida que mostre somente os resultados dos clientes do User4 e colocar um “*” para os outros clientes:
Total Vendas Masked v2 =VAR vUsuarioContexto =
SELECTEDVALUE ( dUsuario[Email] ) // atribui o valor do email do usuário no contexto do visual para a variável
VAR vUsuarioLogado =
USERNAME () // atribui o valor do email do usuario logado para a variável
VAR vClientesFiltrados =
CALCULATETABLE (
VALUES ( UsuarioCliente[ID Cliente] );
dUsuario[Email] = USERNAME ()
) //cria uma tabela virtual com os clientes do usuário logado
VAR vReturn =
SWITCH (
TRUE ();
HASONEVALUE ( dCliente[ID Cliente] )
&& NOT ( SELECTEDVALUE ( dCliente[ID Cliente] ) IN vClientesFiltrados ); “*”;
//verifica se está no nível de cliente e se aquele cliente não está na tabela virtual criada, caso não esteja atribui “*”
HASONEVALUE ( dUsuario[ID Usuario] )
&& vUsuarioContexto <> vUsuarioLogado; “*”;
// verifica se é só existe um valor (para gerentes tem mais de uma valor) e se as variáveis do contexto de usuário e usário logado são diferentes, se sim retorna “*” se não retorna o valor da medida de vendas
[Total Vendas]
)
RETURN
IF ( [Total Vendas]; vReturn )
Bom, tudo isso feito…mas e o resultado? Vamos colocar essa medida ao lado da primeira na tabela com os clientes:
Figura 59: Tabela com as duas medidas para comparação
Máscara 3
E aí, complicado? Fácil? Se anima aí, toma uma água um café leia de novo e bora continuar! O desafio final com a máscara é mostrar o total somente para os clientes daquele usuário. Olha novamente o resultado da tabela passada:
Figura 60: Resultado dos totais igual
Para alterar o resultado do total, temos que criar uma nova medida:
Total Vendas Masked v3 =VAR vUsuarioContexto =
SELECTEDVALUE ( dUsuario[Email] ) // atribui o valor do email do usuário no contexto do visual para a variável
VAR vGerenteContexto =
SELECTEDVALUE ( dUsuario[Gerente] ) // atribui o valor do Gerente no contexto do visual para a variável
VAR vUsuarioLogado =
USERNAME () // atribui o valor do email do usuario logado para a variável
VAR vGerenteLogado =
LOOKUPVALUE ( dUsuario[Gerente]; dUsuario[Email]; USERNAME () ) // busca o valor do Gerente do usuario logado e atribui o valor para a variável
VAR vTotalGerente =
// Calcula o total de vendas dos clientes para aquele Gerente, ou seja, o total da carteira do usuário
CALCULATE (
[Total Vendas];
KEEPFILTERS ( dUsuario[Gerente] = vGerenteLogado )
)
VAR vReturn =
SWITCH (
TRUE ();
vUsuarioContexto = vUsuarioLogado; [Total Vendas];
// se o usuário do contexto é igual ao logado retorna o valor de total de vendas para aquela linha
vGerenteContexto = vGerenteLogado
&& HASONEVALUE ( dUsuario[ID Usuario] ); “*”;
//verifica se o Gerente do usuário no contexto é igual ao Gerente do usuário logado e se existe só um valor para o usuário, ou seja, não é gerente. Retorna “*” se verdadeiro
vTotalGerente
)
RETURN
IF ( ISBLANK ( vReturn ) && [Total Vendas]; “*”; vReturn )
E o resultado, fica assim:
Figura 61: Resultado dos totais diferentes
Segurança de página
Essa é uma funcionalidade nova no Power BI que permite fazer a navegação entre páginas somada ao RLS limitando o acesso das páginas dependendo do usuário logado.
O primeiro passo é criar as páginas, no nosso caso: Home, Por Produto e Por Cliente.
| Importante: Os nomes das páginas devem ser fixos e consistentes. Se você alterar o nome da página depois de finalizar os relacionamento irá perder vínculos, pois a atribuição de nomes não é dinâmica. |
Depois disso, você cria uma tabela dimensão com as informações de páginas do relatório:
Figura 62: Tabela dPagina
Deve existir uma regra de quais usuários podem acessar quais páginas, e essa regra é apresentada pela tabela de relação UsuarioPagina:
Figura 63: Tabela UsuarioPagina
A nossa tabela dUsuario vai propagar os filtros em duas direções. Uma no sentido da tabela de Vendas para filtrar o resultado apresentado. A outra é no sentido da tabela dPaginas. Então, o relacionamento do modelo fica assim:
Figura 64: Relacionamentos da dUsuario no modelo
Figura 65: Relacionamentos da dUsuario e dUsuario
Figura 66: Relacionamento entre UsuarioPagina e dPaginas
E o último passo é criar a regra de função para o usuário, bem simples como já fizemos para os outros casos:
Figura 67: Criação de regra por e-mail
Figura 68: Aplicação do filtro em DAX
[Email] =USERNAME ()
Etapas: Em "Modelagem" selecionar "Gerenciar funções" → Selecionar "Criar" → Nomear a função → Selecionar a tabela dUsuario → Selecionar "Adicionar Filtro" → Selecionar coluna [Email] → Atribuir o filtro DAX
E agora, vamos testar? Primeiro para o famoso User4:
Figura 69: Seleção de usuário para exibição
Figura 70: Página Home do User4
Etapas:
Em "Modelagem" selecionar "Exibir como" → Preencher o usuário e selecionar a regra criada
Veja que a página de análise por produto não aparece para o User4, pois na tabela UsuarioPagina não existe essa relação. E se formos na página de análise por cliente:
Figura 71: Página Por Cliente do User4
E também, vamos fazer o teste para o meu usuário que tem acesso a todas informações e páginas:
Figura 72: Filtro e página para o usuário Leonardo
Figura 73: Resultado da análise por cliente
Eu mostrei o uso, mas faltou mostrar a criação do botão para navegação e as medidas que serão utilizadas nele:
Medidas:Pagina Destino =
SELECTEDVALUE ( dPaginas[Pagina] )
// trás o valor da página selecionado na segmentação de dados para a medida
Pagina Clique =
IF ( [Pagina Destino] = “Home”; “Home”; “Realizar Análise “ & [Pagina Destino] )
// caso a página selecionada for Home mostra Home mesmo,se não adiciona o texto de “Realizar Análise” antes
E a edição do botão fica dessa forma:
Figura 74: Edição de texto dinâmico para o botão
Figura 75: Edição de navegação para o botão
Com isso, finalizamos nosso último exemplo!
Gostaria de compartilhar também um artigo que o Arthur de Oliveira escreveu sobre RLS e Navegação dinâmica:
Dá uma olhada que é material de qualidade!
Galera, esse foi o conteúdo da Live #29!! Eu acredito ter coberto tudo sobre RLS, segurança de colunas e de páginas e espero que seja muito útil no dia a dia de vocês! Não considero um assunto simples dependendo a aplicação, porém tenho a certeza que acompanhando o passo a passo você vai entender.
Se tiver dúvidas ou sugestões para os próximos temas da Lives, já sabe, pode deixar nos comentários.
Abraço,
Leonardo
