Gérer les autorisations avec des projets

Les projets peuvent simplifier la gestion des autorisations grâce à des fonctionnalités telles que les projets imbriqués, la visibilité des projets, les responsables de projets non administrateurs et le verrouillage des autorisations.

Conseil : La manière dont les autorisations sont définies au niveau du projet est importante, en particulier pour le projet par défaut. Lorsqu’un nouveau projet de niveau supérieur est créé, il hérite de ses règles d’autorisation par défaut (pour tous les types de contenu) du projet par défaut. Lors de la création d’un nouveau projet imbriqué dans un autre projet, le projet enfant hérite ses règles d’autorisation par défaut du projet parent.

Administration des projets

Les projets sont des conteneurs utilisés pour organiser et gérer l’accès au contenu. En donnant aux non-administrateurs le droit de gérer des projets, certaines tâches d’administration de contenu peuvent être gérées au niveau du projet.

Responsables de projets : les projets peuvent avoir des responsables de projets, des utilisateurs à qui l’on a accordé la fonctionnalité Responsable du projet . Ce paramètre accorde automatiquement à l’utilisateur ses fonctionnalités maximales - en fonction de son rôle sur le site - pour ce projet et tout son contenu. Les responsables de projets ayant le rôle sur le site Explorer (peut publier) ou un rôle supérieur auront accès à toutes les fonctionnalités. Les responsables de projets sont essentiellement des administrateurs locaux du projet sans accès aux paramètres du site ou du serveur.

Hiérarchie : seuls les administrateurs peuvent créer des projets de premier niveau. Les propriétaires de projets et les responsables de projets peuvent créer des projets imbriqués à l’intérieur de leurs projets.

Les propriétaires et les responsables de projets disposent d’un accès administratif complet au projet et à son contenu, ainsi qu’à tous les projets imbriqués qu’il contient. Dans une hiérarchie, les responsables de projets ont implicitement accès à tout le contenu enfant. Pour supprimer l’accès d’un responsable de projet, vous devez le faire au niveau du parent dans la hiérarchie sur laquelle le rôle a été explicitement attribué.

Propriété : Un projet peut avoir plusieurs responsables de projets, mais chaque projet a exactement un propriétaire. Par défaut, un projet appartient à l’utilisateur qui l’a créé. 

Le propriétaire d’un projet peut être modifié par le propriétaire existant ou par un administrateur. (Les responsables de projets ne peuvent pas modifier la propriété du projet, mais seulement celle du contenu). Les projets peuvent appartenir à des utilisateurs ayant un rôle sur le site Explorer (peut publier), Creator ou administrateur. La propriété d’un projet peut être modifiée même si le projet est verrouillé.

Suppression : la plupart du contenu ne peut exister qu’à l’intérieur d’un projet. Seuls les administrateurs peuvent créer et supprimer des projets de niveau supérieur, mais les responsables de projets peuvent créer ou supprimer des projets imbriqués.

La suppression de projets supprime également tous les contenus Tableau et projets imbriqués qu’ils contiennent. Pour supprimer un projet sans perdre son contenu, déplacez d’abord le contenu vers un autre projet. La suppression de projets ne peut pas être annulée.

Les ressources externes sont traitées différemment. Elles ne doivent pas nécessairement faire partie d’un projet. Les ressources externes ne sont pas supprimées si leur projet est supprimé et apparait néanmoins dans Ressources externes. Consultez Ressources externes non intégrées dans des projets pour en savoir plus.

Pour plus d’information sur l’administration des projets, consultez Utiliser des projets pour gérer l’accès au contenu et Ajouter des projets et déplacer un contenu vers des projets.

Projets spéciaux

Défaut : le projet nommé « Défaut » est un projet spécial. Lorsque d’autres projets de niveau supérieur sont créés, ils utilisent le projet par défaut comme modèle et en copient toutes leurs règles d’autorisations (mais pas le paramètre Autorisations de ressource). Le projet par défaut ne peut pas être supprimé, déplacé ou renommé, mais sa description peut être modifiée. Il n’a pas de propriétaire par défaut, mais un peut lui être attribué.

Projet par défaut pour les ressources externes : Dans Tableau Cloud et Tableau Server 2023.1 et les versions ultérieures, si vous disposez de la licence Data Management avec Catalog activé, le projet nommé « Projet par défaut pour les ressources externes » apparaît lorsque Catalog doit y déplacer des ressources externes nouvelles ou existantes. Catalog intègre les nouvelles ressources externes et les ressources externes des projets supprimés dans le Projet par défaut des ressources externes. Le projet n’a pas de règles d’autorisation définies par défaut, de sorte que les administrateurs de serveur et de site sont les seuls utilisateurs qui peuvent le voir, à moins que des autorisations ne soient ajoutées. Il ne peut pas être supprimé, déplacé ou renommé, mais sa description peut être modifiée. Il n’a pas de propriétaire par défaut, mais un peut lui être attribué.

Désigner un responsable de projet

Les responsables de projets sont des utilisateurs qui ont un accès de type administrateur pour un projet spécifique ou une hiérarchie de projets.

Pour attribuer le statut de responsable de projet à un groupe ou à un utilisateur

  1. Ouvrez la boîte de dialogue Autorisations pour le projet approprié.
  2. Sélectionnez une règle d’autorisation existante, ou cliquez sur + Ajouter une règle de groupe/utilisateur et choisissez le groupe ou l’utilisateur souhaité.
  3. Ouvrez le menu Actions (...) pour cette règle d’autorisations et sélectionnez Définir le responsable du projet....

Remarque : Si le menu Actions comprend une option permettant d’Activer « Définir le responsable du projet », celle-ci doit être sélectionnée pour que le groupe ou l’utilisateur puisse être défini comme responsable du projet. Cette option n’apparaît que lorsque ce groupe ou cet utilisateur s’est vu refuser la fonctionnalité de responsable de projet (avant 2020.1). Cette fonctionnalité refusée doit être supprimée avant qu’ils puissent être désignés comme responsable de projet.

Une fois qu’une règle d’autorisation a établi un responsable de projet, les modèles et les fonctionnalités ne sont pas modifiables car les responsables de projets ont accès à toutes les fonctionnalités. Si un responsable de projet est établi sur un projet qui contient des projets imbriqués, il hérite du statut de responsable de projet sur tous les projets imbriqués et leur contenu.

Le statut de responsable de projet est toujours appliqué de manière descendante dans toute la hiérarchie du projet et ne peut être supprimé qu’au niveau où il a été défini. Pour supprimer le statut de responsable de projet, suivez les mêmes étapes mais sélectionnez Supprimer en tant que responsable du projet dans le menu Actions. Une fois qu’un groupe ou un utilisateur a été supprimé en tant que responsable de projet, toutes les fonctionnalités de cette règle d’autorisation sont réglées sur Non spécifié. Cela peut signifier que son accès et ses fonctionnalités pour ce projet sont supprimés si aucune autre règle d’autorisation ne leur donne accès au contenu. Pour conserver leur accès au projet et à son contenu, ils doivent disposer de fonctionnalités définies comme tout autre groupe ou utilisateur.

Remarque : Les responsables de projets peuvent actualiser des extraits dans leurs projets dans la plupart des cas. Ils ne pourront pas actualiser les extraits s’ils sont uniquement responsables d’un projet imbriqué (plutôt qu’un projet de niveau supérieur) et que le projet de niveau supérieur est verrouillé (y compris les projets imbriqués).

Verrouiller les autorisations des ressources

Les règles d’autorisation définies au niveau du projet agissent par défaut pour le contenu sauvegardé dans ce projet et tous les projets imbriqués qu’il contient. Selon le paramètre d’autorisation de la ressource, ces règles par défaut sont appliquées au niveau du projet ou seulement à titre préliminaire. Ce paramètre peut être configuré de deux façons, soit Verrouillé (recommandé), soit Personnalisable. Si un projet est verrouillé, les propriétaires de contenu ne peuvent plus modifier les règles d’autorisation de leur contenu. Le verrouillage des autorisations peut être appliqué à des projets imbriqués ou simplement au projet parent lui-même.

  • Lorsque les autorisations des ressources sont verrouillées (y compris les projets imbriqués), les règles d’autorisation définies sur le projet sont appliquées pour tout le contenu du projet et tous les projets imbriqués.
  • Lorsque les autorisations des ressources sont verrouillées (à l’exclusion des projets imbriqués), les règles d’autorisation définies sur le projet sont appliquées pour les ressources du projet. Les projets imbriqués peuvent être configurés indépendamment avec leurs propres règles d’autorisation et être définis comme étant verrouillés ou personnalisables.
  • Lorsque les autorisations des ressources sont personnalisables, les règles d’autorisation définies au niveau du projet sont appliquées par défaut à toutes les ressources du projet. Toutefois, les règles d’autorisation peuvent être modifiées pour des ressources individuelles pendant ou après la publication.

Remarque : Que les règles d’autorisation soient verrouillées ou personnalisables, les autorisations sur le contenu sont toujours appliquées. Les termes « verrouillé » et « personnalisable » font uniquement référence à la manière dont les autorisations au niveau du projet sont héritées par le contenu du projet et à qui peut les modifier. Même dans un projet avec des autorisations personnalisables, seuls des utilisateurs spécifiques peuvent modifier les autorisations (le propriétaire du contenu ou du projet, le responsable du projet, les administrateurs ou ceux qui sont autorisés à définir des autorisations).

Dans un projet verrouillé :

  • Les règles d’autorisation de projet par type de contenu sont appliquées à toutes les ressources.
  • Seuls les administrateurs, les propriétaires de projets et les responsables de projets peuvent modifier les autorisations.
  • Les propriétaires de contenu perdent la fonctionnalité Définir l’autorisation mais conservent toutes les autres fonctionnalités sur leur contenu.
  • Les autorisations sont prévisibles pour tout le contenu d’un projet.

Dans un projet personnalisable :

  • Les règles d’autorisation de niveau supérieur sont appliquées par défaut lorsque le contenu est publié dans le projet ou que des projets imbriqués sont créés, mais les autorisations peuvent être modifiées pendant la publication du projet ou après sa création.
  • Tout utilisateur disposant de la fonctionnalité Définir les autorisations peut modifier les règles d’autorisation pour ce contenu.
  • Les propriétaires de contenu ont toutes les fonctionnalités sur leur contenu.
  • Les autorisations peuvent être différentes selon le contenu du projet.

Définir les autorisations des ressources (verrouiller un projet)

Les nouveaux projets de niveau supérieur héritent de toutes les règles d’autorisation initiales du projet par défaut, mais pas du paramètre d’autorisation des ressources, qui est défini sur Personnalisable. Il est possible de le modifier sur Verrouillé le cas échéant.

Pour configurer les autorisations des ressources :

  1. Vous devez être connecté au site en tant qu’administrateur, propriétaire du projet ou responsable du projet.
  2. Ouvrez la boîte de dialogue Autorisations pour un projet.
  3. En regard des autorisations des ressources dans le coin supérieur gauche, cliquez sur le lien Modifier et sélectionnez l’option souhaitée dans la boîte de dialogue Autorisations des ressources

Remarque : Si le coin supérieur gauche n’affiche pas de lien Modifier à l’étape 3 ci-dessus, vous êtes peut-être sur la boîte de dialogue des autorisations pour (a) un projet imbriqué ou un élément de contenu dans un projet verrouillé, auquel cas le lien devrait vous amener au projet gestionnaire, (b) un élément de contenu dans un projet personnalisable, qui n’affichera rien, ou (c) une vue, qui indiquera comment les autorisations de vue sont liées au classeur. Pour plus d’information sur l’interaction des autorisations pour les vues et les classeurs, consultez Afficher ou masquer les onglets de feuille.

Modifier les autorisations des ressources

Lorsque le paramètre d’autorisation des ressources d’un projet est modifié, le résultat dépend du nouveau paramètre. Les modifications des règles d’autorisation dans une hiérarchie verrouillée doivent être effectuées au niveau du projet gestionnaire.

Changer dePasser àRésultat
Verrouillé (y compris les projets imbriqués)Verrouillé

Ne modifie pas les règles d’autorisation existantes.

Tous les projets imbriqués deviennent personnalisables.

Personnalisable

Ne modifie pas les règles d’autorisation existantes, bien qu’elles deviennent personnalisables.

Tous les projets imbriqués deviennent personnalisables.

VerrouilléVerrouillé (y compris les projets imbriqués)

Remplace les règles d’autorisation personnalisées existantes pour tous les projets imbriqués et leur contenu. Cette opération ne peut être annulée.

Personnalisable

Ne modifie pas les règles d’autorisation existantes, bien qu’elles deviennent personnalisables.

Tous les projets imbriqués conservent leurs paramètres d’autorisation de contenu et leurs règles d’autorisation.

PersonnalisableVerrouillé (y compris les projets imbriqués)Remplace les règles d’autorisation personnalisées existantes pour le contenu du projet, et tous les projets imbriqués et leur contenu. Cette opération ne peut être annulée.
Verrouillé

Remplace les règles d’autorisation personnalisées existantes pour le contenu du projet. Cette opération ne peut être annulée.

Tous les projets imbriqués conservent leurs règles d’autorisation et restent personnalisables.

Déplacer des projets et un contenu

Déplacer le contenu Tableau et les ressources externes

Lorsque le contenu Tableau ou les ressources externes sont déplacés entre des projets avec des paramètres d’autorisation différents, les paramètres d’autorisation des ressources déterminent la logique d’application des autorisations.

  • Le déplacement des ressources dans un projet verrouillé remplace les règles d’autorisation existantes et applique les autorisations de la destination.
  • Le déplacement des ressources dans un projet personnalisable maintient les règles d’autorisation existantes sur la ressource.

Remarque : Avant Tableau Server 2022.3 et Tableau Cloud juin 2022, les ressources externes ne pouvaient pas être intégrées dans des projets, et les autorisations sur les tables étaient gérées par le paramètre d’autorisations des tables de la base de données parente. Depuis Tableau Server 2022.3 et Tableau Cloud juin 2022, les ressources externes peuvent être intégrées dans des projets. Si une base de données ou une table est déplacée dans un projet, les anciens paramètres permettant de contrôler les autorisations de la table par l’intermédiaire de la base de données sont ignorés et les autorisations de la base de données ou de la table suivent la logique des autres ressources

Déplacer des projets

Lorsqu’un projet est déplacé dans un autre projet, les paramètres d’autorisation de l’élément déplacé sont conservés, à moins que le projet de destination ne soit défini de manière à inclure des projets imbriqués. (Dans ce cas, les autorisations de projet désignent les fonctionnalités d’affichage et de publication du projet lui-même.)

  • Si le projet de destination est verrouillé (y compris les projets imbriqués), les autorisations pour le projet déplacé et son contenu sont remplacées.
  • Si le projet de destination est défini sur verrouillé (à l’exception des projets imbriqués), les autorisations relatives au projet déplacé ne sont pas remplacées. Le paramètre d’origine est conservé pour l’option spécifiant si le projet déplacé est verrouillé ou personnalisable.
  • Si le projet de destination est défini sur personnalisable, les autorisations du projet déplacé ne sont pas remplacées mais elles sont désormais modifiables.
  • Si le projet déplacé était auparavant imbriqué sous un parent qui était verrouillé (y compris les projets imbriqués), lorsqu’il est déplacé, le projet prend le statut de verrouillé (y compris les projets imbriqués) et devient le projet gestionnaire de tous les projets qu’il contient. Remarque : Le résultat est identique si un projet est déplacé pour devenir un projet de niveau supérieur.

Déplacer les projets imbriqués verrouillés avec prudence

Il peut être difficile de déplacer des projets imbriqués dans des environnements verrouillés (y compris les projets imbriqués). Un projet peut être déplacé dans une situation qui empêche l’utilisateur de le déplacer à nouveau.

Si un projet imbriqué appartient à un utilisateur différent de celui qui gère le projet et que la gestion du projet est définie sur verrouillé (y compris les projets imbriqués), il peut arriver que ce projet imbriqué ne puisse pas être déplacé par quiconque, hormis un administrateur.

Prenons l’exemple d’un projet de niveau supérieur verrouillé (y compris les projets imbriqués) appartenant à l’utilisateur A, et de deux projets imbriqués appartenant à l’utilisateur B. Si l’utilisateur B déplace un projet imbriqué dans l’autre, il ne pourra pas le déplacer à nouveau, et l’utilisateur A non plus.

  • L’utilisateur B ne pourra pas déplacer le Projet imbriqué 2 car il n’est pas autorisé à utiliser le projet de niveau supérieur comme destination de déplacement.
  • L’utilisateur A ne pourra pas déplacer le Projet imbriqué 2 car il n’est pas autorisé à le déplacer.
  • Un responsable de projet sur un projet de niveau supérieur ne peut pas le déplacer, même si les droits de ce responsable de projet s’étendent aux projets imbriqués.
  • Seul un administrateur est capable de déplacer le projet imbriqué 2 dans cette configuration.

Projet de niveau supérieur portant une icône de verrouillage et le nom « utilisateur A », dans lequel apparaît le « projet imbriqué 1 », à l’intérieur duquel se trouve le « projet imbriqué 2 ». Les deux projets imbriqués appartiennent à l’utilisateur B.

Collections

À la différence des projets, qui incluent un contenu, une collection peut être considérée comme une liste de liens vers un contenu. Les autorisations du projet peuvent être héritées par le contenu du projet, mais les autorisations pour une collection n’ont aucun effet sur le contenu ajouté à la collection. Cela signifie que différents utilisateurs peuvent voir différents nombres d’éléments dans une collection, selon les éléments qu’ils sont autorisés à afficher. Pour vous assurer que les utilisateurs peuvent voir tous les éléments d’une collection, ajustez les autorisations pour ces éléments individuellement.

Les autorisations pour une collection peuvent être modifiées soit à l’aide de la boîte de dialogue des autorisations, soit en accordant l’accès lors du partage d’une collection, si vous êtes administrateur ou propriétaire de la collection. Pour plus d’information, consultez Gérer les autorisations des collections.

Collections privées

Lorsqu’une collection est créée, elle est privée par défaut. Une collection privée apparaît dans la page Mes collections du propriétaire, mais elle n’apparaît pas dans la liste de toutes les collections d’un site. Les collections privées sont simplement des collections auxquelles aucune règle d’autorisation n’a été ajoutée. Contrairement à d’autres types de contenu, le groupe « Tous les utilisateurs » n’est pas ajouté par défaut aux collections. Lorsque vous ajoutez des règles d’autorisation à une collection, elle n’est plus marquée comme privée. Pour rendre une collection à nouveau privée, supprimez les règles d’autorisation.

Les collections privées peuvent être consultées par le propriétaire de la collection ainsi que par les administrateurs, dont le rôle sur le site leur donne des autorisations effectives pour afficher toutes les collections.

Merci de vos commentaires!Votre commentaire s été envoyé avec succès. Merci!