Skip to content

Qui peut voir quoi, et comment Tableau le calcule

Une question de permission se pose comme une recherche et se comporte comme un calcul. Les entrées, l’ordre dans lequel elles se résolvent, pourquoi la réponse demande six écrans, et ce qu’une couche en lecture seule peut vous en dire sans rien toucher.

Mis à jour · 7 min de lecture

La question derrière chaque revue des accès

Demander si une personne donnée peut ouvrir un tableau de bord donné ressemble à une recherche. Cela se comporte comme un calcul, sur des entrées qui se trouvent à des endroits différents et sont modifiées par des gens différents à des jours différents.

  • Le rôle de site, qui fixe le plafond de tout ce qui est en dessous.
  • Les règles de permission écrites sur le contenu lui-même.
  • Les règles sur le projet où il se trouve, et si ce projet gère les permissions du contenu qu’il contient.
  • Chaque groupe auquel la personne appartient, chacun pouvant porter sa propre règle.
  • Les règles sur la source de données publiée derrière le contenu, qui se définissent séparément du contenu.
  • Tout filtrage de lignes dans les données, qui décide de ce qui apparaît une fois la vue ouverte.

Six entrées, et l’écran que vous regardez à cet instant en montre généralement une. C’est toute la difficulté, et c’est une propriété de tout modèle de permissions en couches, pas un défaut de celui-ci.

Comment les pièces se combinent

Une capacité se résout pour une personne dans un ordre fixe, et connaître cet ordre transforme la plupart des surprises en une réponse de cinq minutes.

  1. Le rôle de site d’abord. Il plafonne ce qui est possible : une capacité accordée au-delà de ce que le rôle permet n’a aucun effet le jour venu.
  2. Puis la propriété et la direction de projet. Le propriétaire d’un contenu, et un responsable du projet qui le contient, portent les capacités sur celui-ci.
  3. Puis les règles écrites directement pour la personne. Une capacité placée sur Refusé pour cet utilisateur tranche la question, et une capacité placée sur Autorisé pour cet utilisateur la tranche dans l’autre sens.
  4. Puis les règles écrites pour les groupes auxquels la personne appartient. Un refus dans n’importe quel groupe l’emporte sur une autorisation dans un autre, et c’est là que l’accès accidentel commence généralement.
  5. Puis ce qui reste. Non spécifié est l’état de repos, il n’accorde rien, et c’est la bonne valeur à laisser à la plupart des capacités.

Deux règles portent presque tout. Une règle écrite pour une personne bat une règle écrite pour un groupe, et un refus bat une autorisation au même niveau. La plupart des surprises d’accès se ramènent à l’une de ces deux règles, généralement la seconde, et généralement parce que quelqu’un a rejoint un groupe portant un refus posé il y a des années pour une raison sans rapport.

Le projet est l’unité qui porte la permission

Le contenu hérite de l’endroit où il se trouve. Un projet peut détenir un modèle par défaut appliqué au contenu qui y est publié, et un projet peut être réglé pour gérer les permissions de tout ce qu’il contient, ce qui remonte la décision de l’élément au projet.

Une conséquence mérite d’être dite clairement, parce que c’est celle qui surprend les gens en plein rangement : déplacer du contenu change qui peut le voir. Un déplacement ressemble à du ménage et se comporte comme un changement de permission. C’est exactement pourquoi un plan de départ signale un déplacement entre projets comme un risque nommé pendant que le plan est encore en lecture seule, avant que quoi que ce soit ait été modifié.

Publier est le même événement vu de l’autre côté. Le nouveau contenu atterrit sous les règles du projet cible, et la publication s’exécute en tant qu’utilisateur connecté, donc elle s’arrête proprement si ce compte n’a pas la permission de publier ou d’écraser sur la cible. Ces deux choses valent bien mieux d’être connues avant une promotion que pendant.

Pourquoi la réponse est lente à atteindre en cliquant

Répondre pour une personne et un tableau de bord signifie ouvrir la vue, le classeur, le projet, les appartenances aux groupes, la source de données publiée et le rôle de site. Six écrans pour une réponse, et la réponse couvre une personne.

Puis elle expire. Le contenu n’a jamais été touché et la réponse a quand même changé.

  • Quelqu’un a rejoint un groupe, ou en a quitté un.
  • Un rôle de site a changé, ce qui déplace le plafond de tout ce que cette personne touche.
  • Un modèle de projet a changé, ou le projet a commencé à gérer les permissions de son contenu.
  • Du contenu a été déplacé d’un projet vers un autre.

Il y a un problème de direction sous tout cela. Une revue des accès demande qui peut voir ceci. Une interface construite pour le travail quotidien est organisée autour de ce que cette personne peut voir. Ce sont deux questions raisonnables, on y répond en parcourant le même graphe dans des directions opposées, et c’est pourquoi la vérification qui prend dix minutes pour une personne prend quinze jours pour un service.

La couche sous la permission

La permission sur le contenu décide si la vue s’ouvre. Ce qui apparaît à l’intérieur peut être réduit encore par un filtrage de lignes, qu’il s’agisse d’un filtre utilisateur dans le classeur, d’une table de droits jointe à la source de données, ou d’une politique appliquée dans l’entrepôt.

Deux phrases sont alors vraies en même temps. Tout le monde dans le groupe peut ouvrir le tableau de bord, et chacun d’eux voit un ensemble de lignes différent. En général, c’est la conception qui fonctionne exactement comme prévu, et c’est aussi la raison la plus courante pour laquelle deux personnes comparent leurs écrans et concluent que la plateforme est cassée.

Notez quel mécanisme fait le rétrécissement, et où il vit. La gouvernance au niveau du champ s’inventorie : un profil de couche sémantique compte quelle fraction des champs porte une décision de classification et la publie comme l’une des cinq composantes de sa note de qualité. Tout ce qui est compté peut être revu. Tout ce qui ne vit qu’à l’intérieur d’un calcul que quelqu’un a écrit en 2021 se redécouvre de la manière coûteuse.

Ce qu’une couche en lecture seule peut vous dire

Une couche de gouvernance se pose sur le site et hérite de ses règles au lieu d’en tenir un second jeu à côté. Ici, c’est écrit dans la connexion elle-même : chaque utilisateur se connecte avec son propre jeton Tableau, et ce jeton, portant ses permissions exactes, est la frontière de chaque lecture, chaque écriture et chaque appel d’assistant fait en son nom.

Ce qui donne à la lecture une propriété agréable. Ce que le produit vous montre est ce que vous auriez déjà pu atteindre, assemblé plus vite et en un seul endroit. Répondre ainsi à une question de permission ne demande aucun compte élevé, et la lecture elle-même ne change rien : le navigateur de site est en lecture seule par construction, sans chemin de publication, sans point de terminaison d’écriture, et rien n’est gardé sur disque au-delà d’une liste de session de ce que vous avez regardé récemment.

Là où la lecture est partielle, elle dit de quelle sorte de partiel il s’agit. Un extrait de métadonnées qui rencontre un catalogue désactivé ou une frontière de permission renvoie un résultat vide avec un avertissement lisible et ne lève pas d’erreur, si bien que le rapport peut distinguer n’a rien trouvé de n’a pas pu regarder. Le score de risque fait de même par l’autre bout : l’exposition, c’est-à-dire l’étendue des permissions sur le contenu concerné, est maintenue à une valeur fixe jusqu’à ce que cette surface soit activée, et la méthodologie publiée le dit dans la même phrase que le score lui-même.

Une vue partielle qui s’annonce est utilisable lundi. Une vue partielle qui a l’air complète est celle qui vous coûte un constat d’audit, parce que tout le monde en aval la lit comme une couverture et que personne ne revérifie un résultat vert.

Transformer la réponse en registre

  1. Fixez la question avant d’ouvrir quoi que ce soit. Nommez la personne ou le groupe, nommez le contenu, nommez la date, parce qu’une réponse d’accès est vraie à un moment, pas en général.
  2. Lisez le rôle de site en premier. Il plafonne tout ce qui est en dessous et c’est l’entrée la moins chère à vérifier.
  3. Parcourez le projet, puis l’élément, puis les groupes, et notez la règle qui a réellement tranché, pas seulement le résultat.
  4. Vérifiez séparément la source de données publiée derrière le contenu. Elle porte ses propres règles et c’est l’entrée le plus souvent sautée.
  5. Notez ce que vous avez pu voir et ce qui est resté hors de vue. Les trous deviennent une partie du registre plutôt qu’un silence en son sein.
  6. Conservez le résultat avec sa date et le nom de la personne qui l’a exécuté.

Les deux derniers points en font une preuve, pas une capture d’écran. Une réponse de permission portant une date, un auteur et une frontière énoncée peut être remise à quelqu’un d’autre et relancée par lui. Tout le reste est le souvenir d’un mardi, et les souvenirs de mardis sont ce que les revues des accès sont censées remplacer.