Ayuda de Tableau Server en Linux

Una regla de permiso establece quiénes son los afectados (un conjunto de grupos, un grupo o un usuario) y qué Capacidades se les permiten, deniegan o cuáles quedan sin especificar. Aunque parece sencillo establecer una regla de permisos y que eso sea todo, puede que no esté claro si un usuario tiene una capacidad debido a su pertenencia a varios grupos y a la interacción de los roles de sitio y la propiedad con las reglas de permisos.

Se evalúan varios factores en un determinado orden, lo que da como resultado los permisos vigentes de un contenido.

Sugerencia: para conseguir que todo sea lo más sencillo posible, nuestras recomendaciones son: (1) establecer reglas de permisos para grupos en lugar de usuarios, (2) administrar los permisos bloqueados a nivel de proyecto en lugar de establecer permisos para contenido individual y (3) eliminar la regla de permisos del grupo Todos los usuarios, o establecer todas las capacidades como Ninguno.

Se permite una capacidad para un usuario si y solo si se cumplen las tres condiciones siguientes:

• Esa capacidad está dentro del alcance de su rol en el sitio.
  
• Tienen esa capacidad:
  • De acuerdo con una situación de usuario específica (como ser el propietario del contenido o un líder de proyecto, o tener el rol de administrador de un sitio).
    O
  • Porque se le ha permitido tener la capacidad como usuario.
    O
  • Porque está en un grupo al que se le ha permitido tener la capacidad y no hay reglas que se la denieguen como usuario o miembro de grupo.
• No hay configuraciones de permisos en conflicto en otro nivel de contenido que tenga prioridad.

Cualquier otra situación deniega al usuario esa capacidad.

Si se pasa el ratón por encima de una capacidad, aparece una descripción emergente en la que se explica el permiso vigente. A continuación, se incluyen algunos ejemplos habituales de por qué los permisos vigentes, es decir, lo que el usuario puede o no puede hacer en la actualidad, pueden parecer diferentes de lo que establece una regla de permisos determinada:

• Un usuario puede tener una capacidad que se le deniega en una regla de permisos porque su rol en el sitio la incluye (administradores).
• Un usuario puede tener una capacidad que se le deniega en una regla de permisos porque su situación de usuario lo permita (porque es el propietario del contenido, o es el propietario o líder del proyecto).
• Un usuario puede carecer de una capacidad que se le permite en una regla de permisos porque ahora su rol en el sitio no lo permite.
• Un usuario puede carecer de una capacidad que se le permite en una regla de permisos porque un grupo o regla de usuario en conflicto se la denegó.
• Un usuario puede carecer de una capacidad que se le permite en una regla de permisos a un nivel de contenido (como un libro de trabajo) porque otro nivel de contenido se la denegó (como una vista).

Evaluar las reglas de permisos

Los permisos en Tableau son restrictivos. A menos que se conceda una capacidad a un usuario, se le deniega el permiso. En la siguiente lógica se evalúa si se permite o deniega una capacidad para un individuo:

1. Rol en el sitio: si un rol en el sitio no permite tener una capacidad, esta se le deniega al usuario. Si el rol en el sitio del usuario permite la capacidad, se evalúan las situaciones concretas del usuario.
   • Por ejemplo, el rol en el sitio Viewer no puede editar contenido web. Consulte Capacidades generales permitidas con cada rol en el sitio para obtener más información sobre lo que puede hacer cada rol en el sitio.
2. Situaciones de usuario específicas: 
   • Si el usuario es un administrador, tiene todas las capacidades en todo el contenido.
   • Si el usuario es propietario de un proyecto o líder de proyecto, tiene todas las capacidades en todo el contenido de sus proyectos.
   • Si el usuario es el propietario del contenido, tiene todas las capacidades* de su contenido.
   • Si no se aplica ninguna de estas situaciones al usuario, hay que evaluar las reglas de usuario.

   * Excepción: los propietarios del contenido no tendrán la capacidad Configurar permisos en proyectos en los que los permisos estén bloqueados. Solo los administradores, propietarios del proyecto y los líderes de proyecto pueden establecer reglas de permisos en proyectos bloqueados.

3. Reglas de usuario: si al usuario se le deniega una capacidad, está deniega. Si se le permite una capacidad, está permitida. Si una capacidad no está especificada, se evalúan las reglas de grupo.
4. Reglas del grupo: si el usuario está en algún grupo al que se le deniega una capacidad, se le deniega también a él. Si el usuario está en un grupo al que se le permite una capacidad (y no está en ninguno al que se le deniegue esa capacidad), se le permite.
   • Es decir, si un usuario es miembro de dos grupos, y a uno se le permite una capacidad y al otro se le deniega la misma capacidad, la denegación tiene prioridad para ese usuario y se le deniega.
5. Reglas establecidas por el grupo: si un usuario es miembro de un grupo en un conjunto de grupos, se denegará cualquier grupo en el conjunto de grupos al que se le niegue una capacidad.
6. Si no se aplica ninguna de las condiciones anteriores, al usuario se le deniega esa capacidad. De hecho, esto significa que las capacidades que se dejan como no especificadas se denegarán.

Por lo tanto, un permiso final vigente permitido ocurre en tres circunstancias:

• Permitido por el rol en el sitio (Administrador de servidor, Creator del administrador de sitio y Explorer del administrador de sitio)
• Permitido porque el usuario es el propietario del contenido, el propietario del proyecto o el líder del proyecto
• Permitido por un grupo, un conjunto de grupos o una regla de usuario (y no denegado por una regla que tenga más prioridad)

Los permisos denegados tienen lugar en tres circunstancias:

• Denegado por el rol en el sitio
• Denegado por una regla (y no permitido por una regla que tenga más prioridad)
• No concedido por ninguna regla

Evaluar los permisos establecidos en varios niveles

Si Permisos de contenido se establece como Personalizables, es posible configurar las reglas de permisos en varios lugares. Existen reglas específicas que determinan qué permisos se aplican al contenido.

• Si hay proyectos anidados, los permisos establecidos a nivel secundario tienen prioridad sobre los permisos establecidos a nivel principal.
• Los cambios en los permisos a nivel de proyecto no se aplican al contenido existente.
• Si hay permisos establecidos sobre el contenido (libro de trabajo, fuente de datos o flujo) durante o después de la publicación, estos tienen prioridad sobre las reglas establecidas a nivel de proyecto.
• Si un libro de trabajo no muestra pestañas de hoja de navegación, los cambios en los permisos a nivel de libro de trabajo no serán heredados por las vistas y cualquier cambio en los permisos debe realizarse en la vista.
• Configurar el libro de trabajo para mostrar pestañas de hoja de navegación anulará los permisos existentes a nivel de vista y los sincronizará con los permisos a nivel de libro de trabajo. Consulte Mostrar u Ocultar pestañas de hojas.

En esta imagen se muestra cómo se evalúan las capacidades en varios niveles de contenido.

Permisos en vistas

En un libro de trabajo que no se encuentra en un proyecto bloqueado: y que está configurado para ocultar las pestañas de navegación, las vistas (hojas, dashboards, historias) heredan los permisos del libro de trabajo en el momento de la publicación, pero cualquier cambio en las reglas de permisos debe realizarse en vistas individuales. Las capacidades de visualización son las mismas que las de los libros de trabajo, excepto las de Sobrescribir, Descargar libro de trabajo/guardar como una copia y Mover, que solo están disponibles a nivel de libro de trabajo.

Recomendamos mostrar las pestañas de navegación de la hoja siempre que sea posible para que las vistas hereden sus permisos del libro de trabajo. Para obtener más información, consulte Mostrar u Ocultar pestañas de hojas.