Permissões em hierarquias de projeto

Como administrador ou líder de projeto, é possível decidir como as permissões são definidas em uma hierarquia de projeto gerenciada por você. No projeto de alto nível em uma hierarquia, é possível definir o projeto como um dos dois estados disponíveis: bloqueado e gerenciado pelo proprietário. As permissões de bloqueio podem ajudar a manter um modelo de permissões previsíveis em uma hierarquia de projeto. Por exemplo, é possível negar aos publicadores a opção de definir permissões explícitas em pastas de trabalho e fontes de dados que eles possuem.

Estados de permissões de projeto: bloqueado e gerenciado pelo proprietário

Você pode bloquear permissões nas hierarquias de projeto no alto nível da hierarquia. Ao bloquear permissões, as configurações do projeto de alto nível são aplicadas a todas as pastas de trabalho, exibições e fontes de dados da hierarquia.

Em uma hierarquia bloqueada de um projeto, apenas os administradores e líderes de projeto com uma função de site adequada podem modificar as permissões, e podem modificá-las apenas no nível mais alto. Os publicadores não podem definir permissões ao conteúdo durante ou após processo de publicação no Tableau Desktop.

Quando as permissões são gerenciadas pelo proprietário (“desbloqueado”), elas se tornam editáveis pelos proprietários do conteúdo e outros usuários com o nível de acesso adequado. Durante a publicação, os usuários têm a opção de definir permissões especificamente na pasta de trabalho ou fonte de dados que estão publicando, a não ser que você negue explicitamente esse recurso aos grupos de que são membros ou a usuários individuais.

Para esclarecer, os proprietários sempre possuem acesso completo de leitura, escrita, entre outros aos conteúdos publicados por eles, mas no estado bloqueado eles não podem fazer alterações.

Observação: se uma pasta de trabalho, fonte de dados ou projeto com permissões editadas for movido para um projeto bloqueado, as permissões colocadas no projeto bloqueado são aplicadas a esse conteúdo. As permissões do conteúdo movido serão bloqueadas.

Quando usar cada estado

Em geral, bloquear os projetos facilita o gerenciamento de permissões. Você só precisa ir a um lugar para ver como estão definidas para todos os conteúdos nesta hierarquia de projeto.

Contudo, isso requer que todos os projetos secundários tenham as mesmas permissões que o nível mais alto. Estes cenários comuns são possíveis apenas ao manter a hierarquia de projeto desbloqueada

  • Quando você deseja criar projetos para diferentes tipos de acesso que sua equipe precisa para o conteúdo em projetos secundários. Essa estratégia está descrita em Configurar projetos, grupos e permissões para o serviço de autoatendimento gerenciado, e requer definir permissões exclusivas a cada projeto secundário.

    Se mantiver as permissões desbloqueadas, ainda poderá definir permissões no nível do projeto principal que deseja estabelecer como padrão a todos os novos projetos secundários. É possível usar grupos para definir explicitamente recursos, inclusive negar o recurso Definir permissões, de forma que os usuários não possam definir permissões no conteúdo do qual não são proprietários. Os usuários sempre poderão definir permissões no conteúdo que lhes pertence nas hierarquias de projetos desbloqueados.

  • Quando, na edição na Web, você deseja permitir que publicadores salvem alterações em pastas de trabalho, mas não as substituam.

    Para obter mais informações, consulte Permitir aos usuários que podem publicar editar, salvar mudanças e baixar novas pastas de trabalho, mas não substituir as existentes.

Como as permissões são avaliadas nas hierarquias de projeto

O diagrama a seguir mostra como as permissões de liderança e de Líder de projeto são aplicadas em uma hierarquia.

  • PL = Líder de projeto
  • O = Proprietário
  • A linha pontilhada indica permissões implícitas “herdadas” em um nível pai.
  • * = O proprietário foi designado explicitamente pelo proprietário do projeto principal.

Diagram showing how permissions are applied in project hierarchies

Como as permissões são aplicadas nas hierarquias de projeto

Ao bloquear a permissão apenas no maior nível de uma hierarquia de projeto, o comportamento a seguir se aplica:

  • Todos os projetos secundários criados em um projeto de nível mais alto usam as permissões padrão definidas no projeto de nível superior (não no projeto padrão), e você não pode modificar as permissões no projeto de nível secundário.

  • As pastas de trabalho, exibições e fontes de dados também usam as permissões padrão do projeto de nível superior.

  • Os usuários, incluindo os proprietários do conteúdo, não podem editar as permissões para pastas de trabalho individuais, exibições e fontes de dados do projeto.

    Quando os usuários publicam pastas de trabalho e fontes de dados do Tableau Desktop, eles não podem definir permissões na caixa de diálogo Publicar, e o conteúdo obtém as permissões padrão do projeto no qual publicam.

  • Os usuários ou grupos com uma função de site adequada e permissões de Líder de projeto no projeto de nível superior obtêm o acesso de Líder de projeto em todos os projetos secundários, suas pastas de trabalho e fontes de dados.

  • Os administradores e proprietários do conteúdo podem alterar a propriedade a qualquer nível na hierarquia.

  • Os administradores e líderes de projeto podem editar as permissões no projeto de nível superior e as alterações serão propagadas em todos os projetos secundários.

Como as permissões são aplicadas nas hierarquias de projeto desbloqueadas

Se as permissões do projeto de nível superior não estiverem bloqueadas, é possível definir as permissões nos projetos secundários da mesma forma que em projetos de nível superior, com exceção do bloqueio de projetos secundários.

Quando um projeto secundário é criado, ele tem as mesmas permissões que o projeto principal. Os usuários obtêm implicitamente as mesmas permissões que possuem no projeto principal.

Se definir permissões no nível secundário, essas configurações têm precedência em relação às permissões definidas no nível principal.

Consulte também

Para saber mais sobre as etapas das práticas recomendadas para implementação de permissões, consulte a documentação a seguir:

Agradecemos o seu feedback. Ocorreu um erro ao enviar seu feedback. Tente novamente ou envie-nos uma mensagem.