Aide de Tableau Server sur Linux

Une règle d’autorisation établit qui est concerné (un ensemble de groupes, groupe ou un utilisateur) et quelles sont les Fonctionnalités qui sont autorisées, refusées ou non spécifiées. Bien qu’il semble simple d’établir simplement une règle d’autorisation et de s’en tenir là, la question de savoir si un utilisateur dispose de telle ou telle fonctionnalité peut ne pas être claire en raison de son appartenance à plusieurs groupes et de l’interaction des rôles sur le site et de la propriété avec les règles d’autorisation.

Plusieurs facteurs sont évalués dans un ordre spécifique, ce qui génère des autorisations effectives pour un élément de contenu.

Conseil : pour simplifier au maximum, nous vous recommandons (1) de définir des règles d’autorisation pour des groupes plutôt que pour des utilisateurs, (2) de gérer les autorisations verrouillées au niveau du projet au lieu de définir des autorisations sur le contenu individuel, et (3) de supprimer la règle d’autorisation du groupe Tous les utilisateurs ou de définir toutes les fonctionnalités sur Aucune.

Une fonctionnalité est autorisée pour un utilisateur si et seulement si les trois conditions suivantes sont toutes remplies :

• Cette fonctionnalité entre dans le cadre de leur rôle sur le site.
  
• Ils disposent de cette fonctionnalité :
  • selon un scénario utilisateur spécifique (par exemple, en tant que propriétaire du contenu ou responsable de projet, ou en tant qu’administrateur du site),
    OU
  • parce que la fonctionnalité leur a été accordée en tant qu’utilisateurs,
    OU
  • parce qu’ils font tous les deux partie d’un groupe à qui cette fonctionnalité a été accordée et qu’aucune règle ne leur refuse cette fonctionnalité en tant qu’utilisateur ou membre d’un autre groupe.
• Aucun paramètre d’autorisation n’entre en conflit avec un autre niveau de contenu qui a la priorité.

Toute autre situation prive l’utilisateur de cette fonctionnalité.

Le survol d’une fonctionnalité fait apparaître une infobulle qui explique l’autorisation effective. Voici quelques exemples courants des raisons pour lesquelles des autorisations effectives - ce que l’utilisateur peut ou ne peut pas faire dans la réalité - peuvent sembler différentes de ce qu’indique une règle d’autorisation donnée :

• Un utilisateur peut avoir une fonctionnalité qui lui est refusée dans une règle d’autorisation parce que son rôle sur le site l’inclut (administrateurs).
• Un utilisateur peut avoir une fonctionnalité qui lui est refusée dans une règle d’autorisation parce que son scénario utilisateur le permet (parce qu’il possède le contenu ou parce qu’il est un propriétaire ou responsable de projet).
• Un utilisateur peut ne pas disposer d’une fonctionnalité qui lui est accordée dans une règle d’autorisation parce que son rôle sur le site ne le permet pas.
• Un utilisateur peut ne pas disposer d’une fonctionnalité qui lui est accordée dans une règle d’autorisation parce qu’une règle de groupe ou d’utilisateur contradictoire la lui a refusée.
• Un utilisateur peut ne pas disposer d’une fonctionnalité qui lui est accordée dans une règle d’autorisation à un niveau de contenu (tel qu’un classeur) parce qu’un autre niveau de contenu lui est refusé (tel qu’une vue).

Évaluer les règles d’autorisation

Les autorisations dans Tableau sont restrictives. À moins qu’une fonctionnalité ne soit accordée à un utilisateur, l’autorisation lui est refusée. La logique suivante évalue si une fonctionnalité est autorisée ou refusée pour une personne :

1. Rôle sur le site : si un rôle sur le site n’autorise pas une fonctionnalité, l’utilisateur est refusé. Si le rôle sur le site de l’utilisateur le permet, des scénarios utilisateur spécifiques sont évalués.
   • Par exemple, un rôle sur le site Viewer ne peut pas être modifié sur le Web. Consultez Fonctionnalités générales autorisées avec chaque rôle sur le site pour plus d’informations sur les possibilités de chaque rôle sur le site.
2. Scénarios utilisateur spécifiques : 
   • Si l’utilisateur est un administrateur, il dispose de toutes les fonctionnalités sur tout le contenu.
   • Si l’utilisateur est un propriétaire de projet ou un responsable de projet, il dispose de toutes les fonctionnalités sur l’ensemble du contenu de ses projets.
   • Si l’utilisateur est le propriétaire du contenu, il dispose de toutes les fonctionnalités sur son contenu.
   • Si ces scénarios ne s’appliquent pas à l’utilisateur, les règles utilisateur sont évaluées.

   *Exception : les propriétaires de contenu n’auront pas la fonctionnalité Définir les autorisations dans les projets où les autorisations sont verrouillées. Seuls les administrateurs, les propriétaires de projets et les responsables de projets peuvent définir des règles d’autorisation dans les projets verrouillés.

3. Règles d’utilisation : Si une fonctionnalité est refusée à l’utilisateur, elle est refusée. S’ils ont droit à une fonctionnalité, elle est autorisée. Si une fonctionnalité n’est pas spécifiée, les règles de groupe sont évaluées.
4. Règles de groupe : Si l’utilisateur fait partie d’un groupe auquel une fonctionnalité est refusée, elle est refusée. Si l’utilisateur fait partie d’un groupe auquel une fonctionnalité est autorisée (et non d’un groupe auquel cette fonctionnalité est refusée), elle est autorisée.
   • Autrement dit, si un utilisateur est membre de deux groupes et que l’un d’eux a droit à une fonctionnalité et que l’autre se voit refuser la même fonctionnalité, le refus a préséance pour cet utilisateur et elle est refusée.
5. Règles définies par le groupe : si un utilisateur est membre d’un groupe dans un ensemble de groupes, tout groupe de l’ensemble de groupes à qui une fonctionnalité a été refusée est alors refusé.
6. Si aucune des conditions ci-dessus ne s’applique, l’utilisateur se voit refuser cette fonctionnalité. En effet, cela signifie que les fonctionnalité laissées non spécifiées seront refusées.

Une autorisation définitive et effective Autorisé s’applique donc dans trois cas de figure :

• Autorisé par le rôle sur le site (Administrateur de serveur, Administrateur de site - Creator, Administrateur de site - Explorer)
• Autorisé parce que l’utilisateur est le propriétaire du contenu, le propriétaire du projet ou le responsable du projet
• Autorisé par une règle de groupe, d’ensemble de groupes ou d’utilisateur (et non refusé par une règle de priorité plus élevée)

Le statut Refusé se produit dans trois circonstances :

• Refusé par le rôle sur le site
• Refusé par une règle (et non autorisé par une règle de priorité plus élevée)
• Non accordé par une règle quelconque

Évaluer les autorisations définies à plusieurs niveaux

Si les Autorisations de ressources sont définies sur personnalisables, il est important de configurer des règles d’autorisation dans plusieurs emplacements. Il existe des règles spécifiques qui déterminent les autorisations qui s’appliquent au contenu.

• S’il y a des projets imbriqués, les autorisations fixées au niveau enfant ont priorité sur les autorisations fixées au niveau parent.
• Les modifications apportées aux autorisations au niveau du projet ne sont pas appliquées au contenu existant.
• Si des autorisations sont définies sur le contenu (classeur, source de données ou flux) pendant ou après la publication, celles-ci ont priorité sur les règles définies au niveau du projet.
• Si un classeur n’affiche pas d’onglets de navigation de feuilles, les modifications apportées aux autorisations au niveau du classeur ne sont pas héritées par les vues et toute modification des autorisations doit être effectuée sur la vue.
• Si vous configurez le classeur de manière à afficher les onglets de navigation de feuilles, les autorisations existantes au niveau de la vue seront remplacées et synchronisées avec les autorisations au niveau du classeur. Consultez Afficher ou masquer les onglets de feuille.

Cette image montre comment les fonctionnalités sont évaluées à travers plusieurs niveaux de contenu.

Autorisations pour les vues

Dans un classeur qui n’est pas un projet verrouillé et qui n’affiche pas les feuilles sous forme d’onglets de navigation, les vues (feuilles, tableaux de bord, histoires) héritent des droits du classeur lors de la publication, mais toute modification des règles d’autorisation doit être effectuée sur des vues individuelles. Les fonctionnalités d’affichage sont les mêmes que celles des classeurs, à l’exception des fonctionnalités Enregistrer, Télécharger le classeur/Enregistrer une copie et Déplacer qui ne sont disponibles qu’au niveau du classeur.

Nous recommandons d’afficher les onglets de navigation des feuilles chaque fois que possible afin que les vues héritent leurs autorisations du classeur. Pour plus d’informations, consultez Afficher ou masquer les onglets de feuille.