Configurar a segurança usando permissões de tabela

Observação

Desde o dia 12 de outubro de 2022, os portais do Power Apps passaram a ser Power Pages. Mais Informações: O Microsoft Power Pages já está disponível para todos (blog)
Em breve, migraremos e mesclaremos a documentação dos portais do Power Apps com a documentação do Power Pages.

Para aplicar a segurança nos portais aos registros individuais, use as permissões de tabela. Você adiciona permissões de tabela às funções Web para que possa definir funções em sua organização que correspondam logicamente aos privilégios e conceitos de propriedade e acesso de registro que são introduzidos ao usar as permissões de entidade. Lembre-se de que um determinado contato pode pertencer a qualquer número de funções e uma determinada função pode conter qualquer número de permissões de tabela. Para obter mais informações: Criar funções da Web para portais.

Embora as permissões para alterar e acessar URLs no mapa do site de um portal sejam concedidas por meio da Autorização de Conteúdo, os administradores de sites também querem proteger seus aplicativos Web personalizados criados com formulários e listas básicos. Para obter mais informações: Definir formulários básicos e Definir listas.

Para proteger esses recursos, as permissões de tabela permitem conceder direitos granulares a entidades arbitrárias e habilitar segurança de nível de registro por meio de definições de relacionamento.

Adicionar permissões de tabela a uma função Web

1. Abra o aplicativo de gerenciamento de portal.

2. Acesse Portais > Funções Web e abra a função Web à qual você deseja adicionar permissões.

3. Em Relacionados, selecione Permissões de Tabela.

4. Selecione Adicionar Permissão de Tabela Existente para adicionar uma permissão de tabela a uma função Web.

5. Procure uma permissão de tabela ou selecione Nova Permissão de Tabela para criar um novo registro de permissão de tabela.

   

Ao criar um registro de Permissão de Tabela, a primeira etapa é determinar a tabela que será protegida. A próxima etapa é definir o tipo de acesso, conforme discutido na seção seguinte, e, para qualquer tipo de acesso que não seja Global, os relacionamentos que definem esse tipo de acesso. Por fim, determine os direitos que estão sendo concedidos à função por meio dessa permissão. Os direitos são cumulativos, portanto, se um usuário estiver em uma função que concede direitos de Leitura e outra que concede permissões de Leitura e Atualização, ele terá direitos de Leitura e Atualização para qualquer registro sobreposto entre as duas funções.

Observação

A seleção de tabelas, como webpage, arquivos da Web outras tabelas de configuração, é inválida e talvez tenha outras consequências não intencionais. O portal informará a segurança de tabelas de configuração com base em controles de conteúdo de acesso, não em permissões da tabela.

Tipo de acesso Global

Se um registro Permissão de Tabela com direitos de Leitura for concedido a uma função com tipo de acesso Global, qualquer contato nessa função terá acesso a todos os registros da tabela definida. Por exemplo, eles podem ver todos os clientes potenciais, todas as contas etc. Esta permissão será respeitada de forma automática por quaisquer listas, mostrando basicamente todos os registros, de acordo com as exibições do Microsoft Dataverse que foram definidas para essa lista. Além disso, se um usuário tentar acessar um registro por meio de um formulário básico ao qual ele não tem acesso, ocorrerá um erro de permissão. Por exemplo, veja este cenário de exemplo para mostrar todas as listagens de carros para todos os usuários autenticados em uma concessionária.

Tipo de acesso Contato

Com o tipo de acesso Contato, um usuário conectado na função para a qual o registro de permissão é definido terá os direitos concedidos por essa permissão apenas para registros que estão relacionados a esse registro de Contato do usuário, por meio de um relacionamento definido.

Em uma lista, esse tipo de acesso significa que um filtro será adicionado às exibições do Microsoft Dataverse apresentadas por essa lista, que recupera somente os registros vinculados diretamente ao usuário atual. (Dependendo do cenário, este relacionamento poderá ser considerado como direitos de propriedade ou gerenciamento). Por exemplo, consulte este cenário de exemplo para mostrar, atualizar e excluir listagens de carros próprios em uma concessionária.

Os formulários básicos possibilitarão somente a permissão adequada para Leitura, Criação, Gravação, etc. se essa relação existir quando o registro for carregado. Mais informações: Definir formulários básicos.

Tipo de acesso Conta

Com o tipo de acesso Conta, um usuário conectado na função para a qual o registro de permissão esteja definido terá os direitos concedidos por essa permissão apenas para registros que estejam relacionados a esse registro de Conta Primária, por meio de um relacionamento definido.

Este tipo de acesso significa que a lista mostrará apenas os registros da tabela selecionada que estejam associados à Conta Primária do usuário. Por exemplo, se uma permissão de tabela permitir acesso de Leitura a uma tabela de cliente potencial com o tipo de acesso Conta, o usuário com essa permissão poderá exibir todos os clientes potenciais somente da Conta Primária do usuário. Por exemplo, veja este cenário de exemplo para permitir que a equipe exiba todas as concessionárias de automóveis de propriedade da empresa.

Tipo de acesso Próprio

O tipo de acesso próprio permite que você defina os direitos de um usuário para seu próprio registro de Contato (Identidade). Os usuários podem usar formulários básicos ou de várias etapas para fazer alterações nos próprios registros de contato vinculados ao seu perfil. A página de perfil padrão tem um formulário interno especial com o qual qualquer usuário pode alterar informações básicas de contato e optar ou não por listas de marketing. Se esse formulário for incluído no seu portal (o que ocorre por padrão), os usuários não precisarão dessa permissão para usá-lo. No entanto, eles precisarão dessa permissão para usar qualquer formulário básico personalizado ou formulários de várias etapas que se destine a seu registro de contato de usuário. Por exemplo, veja este cenário de exemplo que permite que a equipe de uma concessionária atualize seus detalhes de contato em sua página de perfil.

Tipo de acesso Principal

Nesse caso mais complexo, permissões são concedidas para uma tabela que está em um relacionamento distante de uma tabela para a qual um registro de Permissão de Tabela já tenha sido definido. Essa permissão é, na verdade, um registro Secundário da Permissão de Tabela Principal.

O Registro de Permissão Principal define a permissão e o tipo de acesso de uma tabela (provavelmente o tipo de acesso do Contato ou Global, embora Principal também seja possível). Essa tabela talvez esteja relacionada ao Contato (no caso do tipo de acesso Contato) ou seja definida globalmente. Com essa permissão em vigor, é criada uma Permissão secundária que define o relacionamento de outra tabela com a tabela definida no relacionamento principal.

Os usuários em uma função Web que têm acesso a registros definidos pelas Permissões de Tabela Primária também terão direitos, conforme definido pela Permissão secundária para registros relacionados ao registro principal.

Atributos e relacionamentos

A tabela a seguir explica os atributos de permissão de tabela.

Nome	Descrição
Nome	O nome descritivo do registro. Este campo é obrigatório.
Nome da Tabela	O nome lógico da tabela que será protegida ou que definirá o relacionamento de contato ou o relacionamento principal para proteger uma tabela relacionada em uma permissão secundária. Este campo é obrigatório.
Tipo de Acesso (obrigatório)	Global: concede privilégios ao registro de tabela sem qualquer necessidade de um proprietário (contato). Contato: concede privilégios ao registro de tabela que tem um relacionamento direto com um proprietário (contato). Conta: concede privilégios ao registro de tabela que tem um relacionamento com uma conta, que funciona como o proprietário, considerando que a conta seja o cliente primário do contato. Primárias: concede privilégios ao registro de tabela por meio da cadeia de relacionamentos das suas permissões primárias.
Relacionamento para tipo de acesso	Depende do tipo de acesso selecionado. Relacionamento de contato: obrigatório apenas se o Tipo de acesso = Contato. O nome do esquema do relacionamento entre o contato e a tabela especificada pelo campo Nome da Tabela. Relacionamento de conta: obrigatório apenas se o Tipo de acesso = Conta. O nome do esquema do relacionamento entre a conta e a tabela especificada pelo campo Nome da Tabela. Relacionamento principal: necessário somente se uma permissão de tabela primária for atribuída. O nome do esquema do relacionamento entre a tabela especificada pelo campo Nome da Tabela e a tabela especificada pelo campo Nome da Tabela em seu registro de Permissão de Tabela Principal. Permissão de tabela principal: obrigatório apenas se Tipo de acesso = Principal. Observação: os relacionamentos disponíveis ficarão vazios se o Contato ou a Conta não tiver relacionamentos existentes com a tabela selecionada. Para criar relacionamentos de tabela, consulte Visão geral dos relacionamentos de tabela.
Lidas	Privilégio que determina se o usuário pode ler um registro.
Gravação	Privilégio que determina se o usuário pode atualizar um registro.
Criar	Privilégio que determina se o usuário pode criar um registro. O direito de criar um registro para um tipo de tabela não se aplica a um registro individual, mas a uma classe de tabelas.
Delete	Privilégio que determina se o usuário pode excluir um registro.
Acrescentar	Privilégio que determina se o usuário pode anexar outro registro ao registro especificado. Os direitos de acesso Append e Append To funcionam em combinação. Sempre que um usuário anexa um registro a outro, o usuário deve ter ambos os direitos. Por exemplo, se você anexar uma observação a uma ocorrência, é necessário ter direitos de acesso Append na observação e Append to na ocorrência para a operação funcionar.
Acrescentar a	Privilégio que determina se o usuário pode anexar o registro em questão a outro registro. Os direitos de acesso Append e Append To funcionam em combinação, como descrito acima.

Permissões globais para tarefas relacionadas a clientes potenciais

Em um determinado cenário, podemos querer usar uma lista e formulários básicos para exibir todos os clientes potenciais no portal a qualquer um em uma função Web personalizada de Gerenciador de Clientes Potenciais. No Formulário de Edição de Clientes Potenciais, que é iniciado sempre que uma linha de cliente potencial é selecionada na lista, uma subgrade exibirá os Registros de tarefas relacionadas. Esses registros devem ser acessíveis a qualquer indivíduo na função Gerenciador de Clientes Potenciais. Na primeira etapa, forneceremos permissões Globais para clientes potenciais a todos em nossa função Gerenciador de Clientes Potenciais.

Essa função tem uma Permissão de Tabela relacionada para a tabela Cliente Potencial, com um tipo de acesso Global.

Usuários nessa função podem acessar todos os clientes potenciais por meio de formulários e listas de tabelas no portal.

Agora adicionaremos uma permissão secundária à permissão Global de clientes potenciais. Com o registro de Permissão Primária aberto, vá para a subgrade Permissões de Tabela Filho e selecione Nova Permissão de Tabela para adicionar um novo registro.

Selecione a tabela como Tarefas e o tipo de acesso como Principal. Você pode selecionar o relacionamento primário (Lead_Tasks). Essa permissão implica que um contato em uma função Web com a permissão Primária terá uma permissão Global para todas as tarefas relacionadas a clientes potenciais.

Para que sua lista respeite estas permissões:

• As Permissões de tabela devem ser ativadas na lista.

  

• Deve haver ações que realmente permitirão que os usuários façam as ações para as quais suas permissões foram concedidas.

  

• As permissões também devem ser ativadas no registro de formulário básico.

  

• O formulário deve estar exibindo uma página que possui uma subgrade para a tabela que você deseja habilitar com Permissões secundárias. Nesse caso, a tabela será Tarefas.

  

Se quiser habilitar as permissões de Leitura ou Criação para tarefas, você precisará configurar esses formulários básicos e editá-los para remover o campo de consulta Referente a.

Essa ação concederá permissões para todas as tarefas relacionadas a clientes potenciais. Se as tarefas estiverem sendo exibidas em uma lista de entidades, um filtro será adicionado à lista para que apenas as tarefas relacionadas a um cliente potencial apareçam na lista. No nosso exemplo, elas estão sendo exibidas com uma subgrade em um formulário básico.

Permissões com tipo de acesso Contato para tarefas

Outro exemplo seria querer permitir o acesso a tarefas nas quais um contato está relacionado ao cliente potencial primário dessa tarefa. Esse cenário é quase idêntico ao exemplo da seção anterior, exceto que, nesse caso, a Permissão primária terá um tipo de acesso Contato em vez de Global. Um relacionamento deve ser especificado no relacionamento primário entre a tabela Cliente Potencial e a tabela Contato.

Depois que essas permissões estiverem em vigor, os usuários na função Gerenciador de Clientes Potenciais podem acessar clientes potenciais relacionados diretamente a eles, conforme especificado pela permissão de tipo de acesso Contato, e acessar as tarefas relacionadas a esses mesmos clientes potenciais, conforme especificado no registro de Permissão secundária.

Consulte também

Criar funções da Web para portais
Controle de acesso à página da Web para portais

Observação

Você pode nos falar mais sobre suas preferências de idioma para documentação? Faça uma pesquisa rápida. (Observe que esta pesquisa está em inglês)

A pesquisa levará cerca de sete minutos. Nenhum dado pessoal é coletado (política de privacidade).