Ajuda do Tableau Server no Linux

Uma regra de permissão estabelece quem é afetado (um conjunto de grupos, grupo ou usuário) e a quais Recursos eles são permitidos, negados ou não especificados. Embora pareça simples apenas definir uma regra de permissão e essa deve ser a história toda, pode não estar claro se um usuário tem um recurso devido à associação a vários grupos e à interação das funções no site e da propriedade com as regras de permissão.

Diversos fatores são avaliados em uma ordem específica, produzindo permissões efetivas em uma parte do conteúdo.

Dica: para ajudar a manter as coisas o mais objetivas possível, é recomendável (1) definir regras de permissão para grupos, em vez de usuários; (2) gerenciar permissões bloqueadas no nível de projeto, em vez de definir permissões no conteúdo individual; e (3) excluir a regra de permissão do grupo Todos os usuários ou definir todos os recursos como Nenhum.

É permitido um recurso para um usuário somente se as três condições a seguir forem atendidas:

• O recurso está dentro do escopo da função de site
  
• Ele tem esse recurso:
  • com base em um cenário de usuário específico (como ser o proprietário do conteúdo ou um líder de projeto ou ele tem uma função no site de administrador),
    OU
  • porque o recurso foi permitido para ele como um usuário,
    OU
  • porque ele está em um grupo que tem permissão para o recurso e nenhuma regra negou o recurso para ele como usuário ou membro de outro grupo
• Não há configurações das permissões em conflito em outro nível de conteúdo que tenha precedência.

Qualquer outra situação nega o recurso ao usuário.

Passar o cursor sobre um recurso mostra uma dica de ferramenta que explica a permissão efetiva. Estes são alguns exemplos comuns de por que as permissões efetivas (o que o usuário pode ou não fazer realmente) podem parecer diferentes do que determina a regra de permissão:

• Um usuário pode ter um recurso que foi negado a ele em uma regra de permissão, pois sua função no site o inclui (administradores).
• Um usuário pode ter um recurso que foi negado a ele em uma regra de permissão, pois seu cenário de usuário permite (porque ele possui o conteúdo ou é um proprietário ou líder de projeto).
• Um usuário pode não ter um recurso que foi permitido a ele em uma regra de permissão, porque sua função de site agora o permite.
• Um usuário pode não ter um recurso que foi permitido a ele em uma regra de permissão, porque uma regra de grupo ou usuário conflitante o negou.
• Um usuário pode não ter um recurso que foi permitido a ele em uma regra de permissão no nível de conteúdo (como uma pasta de trabalho), porque outro nível de conteúdo o negou (como uma exibição).

Avaliar regras de permissão

As permissões no Tableau são restritas. A menos que um recurso seja concedido a um usuário, a permissão é negada. A lógica a seguir avalia se um recurso é permitido ou negado para um indivíduo:

1. Função de site: se uma função de site não permitir um recurso, o usuário será negado. Se a função no site do usuário permitir o recurso, os cenários de usuário específicos serão avaliados.
   • Por exemplo, uma função de site Viewer não pode editar na Web. Consulte Recursos gerais permitidos com cada função de site, para obter mais informações sobre o que cada função de site pode fazer.
2. Cenários de usuário específicos: 
   • Se o usuário for um administrador, ele terá todos os recursos em todo o conteúdo.
   • Se o usuário for um proprietário ou líder de projeto, ele terá todos os recursos em todo o conteúdo em seus projetos.
   • Se o usuário for o proprietário do conteúdo, ele terá todos os recursos* em seu conteúdo.
   • Se esses cenários não se aplicarem ao usuário, as regras do usuário serão avaliadas.

   *Exceção: os proprietários do conteúdo não terão o recurso Permissões nos projetos em que as permissões estão bloqueadas. Somente administradores, proprietários e líderes de projeto podem definir regras de permissão em projetos bloqueados.

3. Regras de usuário: se um recurso for negado o usuário, ele será negado. Se um recurso for permitido a ele, será permitido. Se um recurso não for especificado, as regras de grupo serão avaliadas.
4. Regras de grupo: se o usuário estiver em qualquer grupo para o qual um recurso for negado, ele será negado. Se o usuário estiver em um grupo para o qual um recurso foi permitido (e não estiver em grupos para os quais esse recurso foi negado), ele será permitido.
   • Ou seja, se um usuário for membro de dois grupos e um recurso for permitido para um e o mesmo recurso for negado para outro, a negação terá precedência para esse usuário e ele será negado.
5. Regras definidas pelo grupo: se um usuário for membro de um grupo em um conjunto de grupos, qualquer grupo no conjunto de grupos cujo recurso tenha sido negado será negado.
6. Se nenhuma das condições acima se aplicar, o recurso será negado para esse usuário. De fato, isso significa que os recursos deixados como não especificados resultarão em negados.

Portanto, uma permissão efetiva final de Permitido ocorre em três circunstâncias:

• Permitido pela função no site (Administrador do servidor, Creator (Administrador de site), Explorer (Administrador de site)
• Permitido porque o usuário é o proprietário do conteúdo, proprietário de projeto ou líder de projeto
• Permitido por uma regra de grupos, conjunto de grupos ou usuário (e não negado por uma regra de precedência superior)

Negado ocorre em três circunstâncias:

• Negado pela função no site
• Negado por uma regra (e não permitido por uma regra de precedência superior)
• Não concedido por qualquer regra

Avaliar as permissões definidas em vários níveis

Se Permissões de ativo são definidos como Personalizáveis, é possível configurar regras de permissão em vários lugares. Há regras específicas que determinam quais permissões são aplicadas no conteúdo.

• Se houver projetos aninhados, as permissões definidas no nível secundário terão precedência sobre as permissões definidas no nível primário.
• As alterações nas permissões no nível do projeto não são impostas para o conteúdo existente
• Se houver permissões definidas no conteúdo (pasta de trabalho, fonte de dados ou fluxo) durante ou após a publicação, elas prevalecerão sobre as regras definidas no nível do projeto.
• Se uma pasta de trabalho não mostrar guias de planilha de navegação, todas as alterações nas permissões no nível de pasta de trabalho não serão herdadas pelos modos de exibição, e quaisquer alterações nas permissões deverão ser feitas no modo de exibição.
• A configuração da pasta de trabalho para mostrar as guias de planilha de navegação substituirá as permissões no nível de exibição existentes e sincronizará com as permissões no nível da pasta de trabalho. Consulte Mostrar ou ocultar as guias de planilha.

Esta imagem mostra como os recursos são avaliados por meio de vários níveis de conteúdo.

Permissões em exibições

Em uma pasta de trabalho que não está em um projeto bloqueado e não mostra planilhas como guias de navegação, as exibições (planilhas, painéis, histórias) herdam as permissões da pasta de trabalho na publicação, mas quaisquer alterações nas regras de permissão devem ser feitas em exibições individuais. Os recursos de exibição são iguais para as pastas de trabalho, exceto Substituir, Baixar pasta de trabalho/Salvar como uma cópia e Mover, que estão disponíveis apenas no nível de pasta de trabalho.

Recomendamos mostrar as guias de planilha de navegação sempre que possível, para que as exibições herdem suas permissões da pasta de trabalho. Para obter mais informações, consulte Mostrar ou ocultar as guias de planilha.