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 les autorisations de verrouillage.

Conseil : la manière dont les autorisations sont définies au niveau du projet est très importante, en particulier pour le projet par défaut. Lorsqu’un nouveau projet de niveau supérieur est créé, il hérite 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) et supérieur disposent de 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 un administrateur. (Les responsables de projet ne peuvent pas modifier la propriété du projet, uniquement la propriété du contenu). Les projets peuvent appartenir à des utilisateurs dotés d’un rôle sur le site Explorer (peut publier), Creator ou administrateur. La propriété du projet peut être modifiée même si un 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 et projets imbriqués Tableau 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 n’ont pas besoin d’être dans un projet. Les ressources externes ne sont pas supprimées si leur projet est supprimé et continuent d’apparaître dans Ressources externes. Voir Ressources externes qui ne sont pas dans des projets pour plus d’informations.

Pour plus d’informations sur l’administration des projets, voir Utiliser des projets pour gérer l’accès au contenu et Ajouter des projets et déplacer un contenu dans ces projets.

Projets spéciaux

Par défaut : le projet nommé « Par 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 d’Autorisations pour les ressources). Le projet Par défaut ne peut pas être supprimé, déplacé ni renommé, mais sa description peut être modifiée. Il n’a pas de propriétaire par défaut, mais un propriétaire peut lui être attribué.

Projet par défaut des ressources externes : dans Tableau Cloud et Tableau Server 2023.1 et versions ultérieures, si vous disposez d’une licence Data Management avec Catalog activé, le projet nommé « Projet par défaut des ressources externes » apparaît lorsque Catalog doit y déplacer des ressources externes nouvelles ou existantes. Catalog place 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, si bien que les administrateurs de serveur et de site sont les seuls utilisateurs autorisés à le voir à moins que des autorisations soient ajoutées. Il ne peut pas être supprimé, déplacé ni renommé, mais sa description peut être modifiée. Il n’a pas de propriétaire par défaut, mais un propriétaire 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 devra être sélectionnée de manière à ce 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 plus modifiables car toutes les fonctionnalités sont autorisées pour les responsables de projets. Si un responsable de projet est établi sur un projet qui contient des projets imbriqués, il aura hérité 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 capacités sont définies sur Non spécifié pour cette règle d’autorisation. Cela peut signifier que l’accès et les capacités du responsable pour ce projet seront supprimés si aucune autre règle d’autorisation ne lui donne accès au contenu. Pour qu’il conserve son accès au projet et à son contenu, il ses capacités devront être définies comme tout autre groupe ou utilisateur.

Remarque : les responsables de projet peuvent actualiser des extraits dans leurs projets dans la plupart des cas. Ils ne peuvent pas actualiser les extraits s’ils ne sont que le responsable de projet d’un projet imbriqué (au lieu d’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 de 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 Autorisations de ressources, 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 de ressources sont verrouillées (y compris les projets imbriqués), les règles d’autorisation définies sur le projet sont appliquées pour toutes les ressources du projet et tous les projets imbriqués.
  • Lorsque les Autorisations de ressources sont verrouillées (sans inclure les projets imbriqués), les règles d’autorisation définies au niveau du projet sont appliquées pour toutes les ressources du projet. Les projets imbriqués peuvent être configurés indépendamment avec leurs propres règles d’autorisation et définis comme verrouillés ou personnalisables.
  • Lorsque les autorisations de 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 de 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 Autorisations de ressources, qui est défini sur Personnalisable. Il est possible de le modifier sur Verrouillé le cas échéant.

Pour configurer les Autorisations de 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. À côté de Autorisations de 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 de 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’informations sur l’interaction des autorisations pour les vues et les classeurs, voir Afficher ou masquer les onglets de feuille.

Modifier les autorisations de ressources

Lorsque le paramètre Autorisations de 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, ainsi que 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 des ressources externes sont déplacés entre des projets avec des paramètres d’autorisation différents, les paramètres Autorisations de ressources déterminent la logique d’application des autorisations.

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

Remarque : avant Tableau Server 2022.3 et Tableau Cloud de juin 2022, les ressources externes ne pouvaient pas se trouver dans des projets et les autorisations sur les tables étaient gérées via le paramètre Autorisations pour les tables dans la base de données parente. Depuis Tableau Server 2022.3 et Tableau Cloud juin 2022, les ressources externes peuvent se trouver dans des projets. Si une base de données ou une table est déplacée dans un projet, les anciens paramètres de contrôle des autorisations pour les tables via la base de données sont ignorés, et les autorisations pour les bases de données ou les tables 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 du projet 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 défini sur 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é (sans inclure les 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 ou non.
  • 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.

Faites attention en déplaçant des projets imbriqués verrouillés

Le déplacement de projets imbriqués dans des environnements verrouillés (incluant les projets imbriqués) peut être délicat. 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 autre utilisateur que le projet de gestion et que le projet de gestion est défini sur verrouillé (incluant les projets imbriqués), un projet imbriqué peut ne plus être déplaçable par quiconque, à l’exception d’un administrateur.

Par exemple, considérons un projet de niveau supérieur verrouillé (incluant les projets imbriqués) appartenant à l’utilisateur A et deux projets imbriqués appartenant à l’utilisateur B. Si l’utilisateur B déplace un projet imbriqué à l’intérieur de l’autre, il ne peut pas l’en retirer, et l’utilisateur A non plus.

  • L’utilisateur B ne peut pas déplacer le Projet imbriqué2 car il n’a pas le droit de déplacer les droits sur le Projet de niveau supérieur comme destination.
  • L’utilisateur A ne peut pas déplacer le Projet imbriqué2 car il ne dispose pas des droits de déplacement pour ce projet.
  • Un responsable de projet pour un Projet de niveau supérieur ne peut pas le déplacer même s’il se rabat sur des projets imbriqués.
  • Seul un administrateur peut déplacer le Projet imbriqué2 dans cette configuration.

Un projet de niveau supérieur avec une icône de verrouillage et le nom « Utilisateur A » à côté, avec « Projet imbriqué1 » à l’intérieur et « Projet imbriqué2 » inclus dedans. Les deux projets imbriqués appartiennent à 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’informations, 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 !Avis correctement envoyé. Merci