Autorisations dans les hiérarchies de projet

En tant qu'administrateur ou que responsable de projet, vous pouvez décider comment les autorisations sont définies dans une hiérarchie de projet que vous gérez. Pour un projet de niveau supérieur dans une hiérarchie, vous pouvez définir un projet sur l'un des deux états disponibles : verrouillé et géré par le propriétaire. Le verrouillage des autorisations peut vous aider à conserver un modèle d'autorisations prévisible dans lune hiérarchie de projet. Par exemple, les publicateurs n'auront pas le droit de définir des autorisations explicites sur les classeurs et les sources de données qu'ils possèdent.

États des autorisations de projet : verrouillé et géré par le propriétaire

Vous pouvez verrouiller les autorisations dans des hiérarchies de projet au niveau supérieur de la hiérarchie. Lorsque vous verrouillez des autorisations, les paramètres d'autorisation du projet de niveau supérieur sont appliqués à tous les classeurs, vues et sources de données dans la hiérarchie.

Dans une hiérarchie de projet verrouillé, seuls les administrateurs et les responsables de projet dotés d'un rôle sur le site approprié peuvent modifier les autorisations, et ils ne peuvent le faire qu'au niveau supérieur. Les publicateurs ne peuvent pas définir d'autorisations sur leur contenu pendant ou après une publication depuis Tableau Desktop.

Lorsque les autorisations sont gérées par le propriétaire (« déverrouillées »), elles peuvent être modifiées par les propriétaires de contenu et autres utilisateurs dotés du niveau d'accès approprié. Pendant la publication, les utilisateurs ont la possibilité de définir des autorisations explicitement pour le classeur ou la source de données qu'ils publient, à moins que vous ne refusiez explicitement cette fonctionnalité pour les groupes dont ils sont membres ou des utilisateurs individuels.

Pour clarifier, les propriétaire bénéficient toujours d'un accès complet en lecture, en écriture et autre accès au contenu qu'ils publient, mais dans un état verrouillé, ils ne peuvent pas modifier les autorisations pour ce contenu.

Remarque : en cas de déplacement d'un classeur, d'une source de données ou d'un projet disposant d'autorisations modifiables vers un projet verrouillé, les autorisations définies pour le projet verrouillé sont appliquées à ce contenu. Les autorisations du contenu déplacé sont ensuite verrouillées.

Dans quels cas utiliser chaque état

En règle générale, les autorisations sont plus faciles à gérer lorsque vous verrouillez les projets. Il vous suffit d'accéder à un seul emplacement pour voir comment elles sont définies pour tout le contenu de cette hiérarchie de projet.

Toutefois, ceci nécessite que tous les projets enfants disposent des mêmes autorisations que celles définies au niveau supérieur. Les scénarios courants suivants sont possibles uniquement lorsque la hiérarchie de projet reste déverrouillée : 

  • Vous souhaitez créer des projets pour différents types d'accès dont votre équipe a besoin pour le contenu des projets enfants. Cette stratégie est décrite dans Configurer des projets, des groupes et des autorisations pour le libre-service géré et exige de définir des autorisations uniques pour chaque projet enfant.

    Si les autorisations restent déverrouillées, vous pouvez toujours définir, au niveau d'un projet parent, les autorisations que vous souhaitez attribuer par défaut à tous les nouveaux projets enfants. Vous pouvez utiliser des groupes pour définir des fonctionnalités explicitement, y compris refuser la fonctionnalité Définir les autorisations, dans quel cas les utilisateurs ne peuvent pas définir les autorisations pour le contenu qu'ils ne possèdent pas. Les utilisateurs seront toujours en mesure de définir des autorisations sur le contenu qu'ils possèdent dans des hiérarchies de projet déverrouillées.

  • Dans la modification sur le Web, vous souhaitez autoriser les publicateurs à enregistrer les modifications apportées à des classeurs, mais pas à les remplacer.

    Pour plus d'informations, consultez Autoriser les utilisateurs qui peuvent publier à modifier, enregistrer et télécharger de nouveaux classeurs nouveaux, mais pas à écraser les classeurs existants.

Mode d'évaluation des autorisations dans les hiérarchies de projet

Le schéma suivant montre comment la propriété et les autorisations de responsable de projet. sont appliquées dans une hiérarchie.

  • PL = Responsable de projet
  • O = Propriétaire
  • Les pointillés indiquent les autorisations explicites « héritées » au niveau du parent.
  • * = Le propriétaire a été désigné explicitement par le propriétaire du projet parent.

Diagram showing how permissions are applied in project hierarchies

Mode d'application des autorisations dans les hiérarchies de projet verrouillé

Vous pouvez verrouiller l'autorisation uniquement au niveau supérieur d'une hiérarchie de projet, et le comportement suivant s'applique :

  • Tous les projets enfants que vous créez dans un projet de niveau supérieur utilisent les autorisations par défaut définies pour le projet de niveau supérieur (non le projet par défaut), et vous ne pouvez pas modifier les autorisations au niveau du projet enfant.

  • Les classeurs, vues et sources de données utilisent également les autorisations par défaut définies pour le projet de niveau supérieur.

  • Les utilisateurs, y compris les propriétaires de contenu, ne peuvent pas modifier les autorisations pour des classeurs, des vues et des sources de données individuels.

    Lorsque les utilisateurs publient des classeurs et des sources de données depuis Tableau Desktop, ils ne peuvent pas définir les autorisations dans la boîte de dialogue Publier, et leur contenu obtient les autorisations par défaut pour le projet sur lequel ils publient.

  • Les utilisateurs ou les groupes dotés d'un rôle sur le site avec autorisations de Responsable de projet pour le projet de niveau supérieur bénéficient d'un accès Responsable de projet à tous les projets enfants ainsi qu'à leurs classeurs et sources de données.

  • Les administrateurs et les propriétaires de contenu peuvent modifier la propriété à tout niveau de la hiérarchie.

  • Les administrateurs et responsables de projet peuvent modifier les autorisations pour le projet de niveau supérieur, et ces modifications se propagent à tous les projets enfants.

Mode d'application des autorisations dans les hiérarchies de projet non verrouillé

Si les autorisations de projet de niveau supérieur ne sont pas verrouillées, vous pouvez définir des autorisations pour ses projets enfants de la même manière que pour les projets de niveau supérieur, à l'exception du verrouillage du projet enfant.

Lorsque vous créez un projet enfant, il reçoit les autorisations par défaut du projet parent. Les utilisateurs obtiennent implicitement les mêmes autorisations qu'ils ont sur le projet parent.

Si vous définissez des autorisations au niveau enfant, ces paramètres ont la priorité sur les autorisations définies au niveau parent.

Voir également

Pour les étapes recommandées de mise en œuvre des autorisations, consultez les sections suivantes :

Merci pour vos commentaires ! Il y a eu une erreur lors de l’envoi de vos commentaires. Essayez à nouveau ou envoyez-nous un message.