Tutoriel : Démarrer un workflow de projet Studio

L’ajout d’un utilisateur à un Projet lui donnera accès (pour les Projets configurés pour restreindre l’accès des participants) ou lui refusera l’accès (pour les Projets non configurés pour restreindre l’accès des participants). L’accès restreint des participants est abordé plus en détail ci-dessous.

Pour ajouter un utilisateur au Projet, suivez les étapes ci-dessous :

1. Lorsque vous êtes dans le Projet, sélectionnez Paramètres du projet dans l’onglet Projet. La boîte de dialogue Paramètres du projet s’affiche.

2. Sélectionnez l'onglet Accès utilisateur. Les utilisateurs précédemment ajoutés apparaîtront dans la liste.

   

3. Pour ajouter de nouveaux utilisateurs individuels, sélectionnez . Dans la boîte de dialogue Ajouter une adresse e-mail, saisissez l'adresse e-mail de l'utilisateur et sélectionnez OK.
4. Pour ajouter les utilisateurs à un Groupe, cliquez sur . Dans la boîte de dialogue Sélectionner des Groupes, sélectionnez le groupe souhaité et cliquez sur OK. Tous les utilisateurs de ce Groupe sont automatiquement ajoutés.
   Seul le maître d’ouvrage du Projet peut utiliser des groupes pour ajouter des utilisateurs au Projet.
5. Par défaut, tous les utilisateurs ajoutés à l'onglet Accès utilisateur ont automatiquement leur Accès défini sur Autorisé. Pour refuser l'accès à un utilisateur spécifique (par exemple, un utilisateur ajouté avec un Groupe qui ne devrait pas avoir accès à ce Projet spécifique), sélectionnez l'utilisateur souhaité et sélectionnez Refuser. La boîte de dialogue Refuser les utilisateurs apparaît : laissez l'option par défaut Ne pas autoriser d'autres personnes à modifier leurs annotations sélectionnée et sélectionnez Refuser l'utilisateur.
6. Pour restreindre l'accès à ce projet uniquement aux utilisateurs listés dans l'onglet Accès utilisateur dont l'accès est défini sur Autoriser, sélectionnez Restreindre les utilisateurs.

   La relation entre ce paramètre et le statut d'**accès** d'un utilisateur (soit **Autoriser**, soit **Refuser**) vous permet de configurer l'équivalent d'une « liste blanche » ou d'une « liste noire » et mérite quelques explications supplémentaires :

   • Lorsque l'option Restreindre les utilisateurs est sélectionnée, seuls les utilisateurs répertoriés ici dans l'onglet Accès utilisateur dont l'Accès est défini sur Autoriser pourront accéder à ce Projet. Ceci est l'équivalent d'une « liste blanche. »
   • Lorsque Restreindre les utilisateurs n'est pas sélectionné, tout utilisateur peut accéder au Projet, à l'exception de ceux figurant ici dans l'onglet Accès utilisateur dont l'Accès est défini sur Refuser. Ceci est l'équivalent d'une « liste noire ».
7. sélectionner OK.
   

Les autorisations définissent les actions que les utilisateurs peuvent effectuer dans le Projet. Les autorisations peuvent être définies pour les groupes ainsi que pour les utilisateurs individuels.

1. Lorsque vous êtes dans le Projet, sélectionnez Paramètres du projet dans l’onglet Projet. La boîte de dialogue Paramètres du projet s’affiche.

2. Sélectionnez l'onglet Autorisations.

   

   Le groupe par défaut, Participants, s’affichera, ainsi que tout autre utilisateur ou groupe ayant été ajouté précédemment. Le groupe Participants s'applique à tous les utilisateurs du Projet et ses paramètres d'autorisation initiaux sont configurés lors de la création du Projet. Il ne peut pas être supprimé. La plupart des autorisations du groupe Participants sont définies sur Refuser lors de la création du Projet ; une bonne pratique recommandée consiste à accorder des autorisations supplémentaires à des utilisateurs et Groupes spécifiques plutôt que d'autoriser un accès plus étendu au groupe Participants.
   

3. Pour ajouter des utilisateurs individuels ou des Groupes:
   1. sélectionner .

   2. Dans la boîte de dialogue Ajouter des utilisateurs/groupes, sélectionnez l’utilisateur ou le groupe souhaité, puis sélectionnez OK. Seuls les groupes du maître d’ouvrage sont affichés car ce sont les seuls qui peuvent être utilisés dans le Projet. Par défaut, lorsque les utilisateurs et les Groupes sont ajoutés, ils héritent des autorisations du groupe Participants.

      Si vous êtes le maître d’ouvrage du Projet et que vous souhaitez créer un nouveau Groupe pour ce Projet ou modifier l’appartenance à un Groupe actuellement utilisé, sélectionnez Gérer les Groupes. Voir Groupes Studio pour plus d’informations sur la création et la gestion des groupes. Les utilisateurs disposant des autorisations de Contrôle total peuvent également utiliser Gérer les Groupes pour gérer leurs propres groupes, mais ils ne pourront pas utiliser ces groupes dans ce Projet ni modifier les Groupes du maître d’ouvrage.

      Lors de la création de Groupes, gardez à l’esprit que Revu permettra à une personne de faire partie de plusieurs Groupes au sein de la même Session ou du même Projet ; dans ce cas, les autorisations de cette personne seront définies par défaut sur la plus restrictive. Ainsi, l’ajout d’une personne déjà membre d’un Groupe à un deuxième Groupe peut ne pas avoir l’effet souhaité, soit en n’accordant pas les autorisations attendues (parce que celles du premier Groupe sont plus restrictives), soit en imposant des restrictions indésirables (parce que celles du second Groupe sont plus restrictives).

4. Pour modifier les autorisations d'un utilisateur ou d'un Groupe:
   1. Sélectionnez l’utilisateur ou le Groupe souhaité dans la liste Utilisateurs/Groupes.
   2. Sélectionnez l'autorisation souhaitée dans la liste Autorisations appliquées.
   3. Sélectionnez un paramètre d’autorisation dans la liste déroulante.
      • Lors de la définition des autorisations pour le groupe Attendees, les options sont Refuser ou Autoriser.
      • Lorsque vous définissez l’autorisation pour tous les autres utilisateurs et Groupes, les options sont vides, Refuser ou Autoriser. La sélection de vide entraînera l’héritage par l’utilisateur ou le Groupe de l’autorisation définie pour le groupe Participants.
      • L'autorisation de **Contrôle total** est puissante et son réglage sur **Autoriser** confère à l'utilisateur ou au Groupe d'utilisateurs des pouvoirs d'administrateur. Les effets de ceci sont :
        • Toutes les autorisations pour les administrateurs sont définies sur Autoriser.
        • Les Administrateurs peuvent renommer le Projet.
        • Les administrateurs peuvent supprimer le Projet.
        • Les administrateurs peuvent gérer l'accès des utilisateurs.
        • Les administrateurs peuvent gérer les autorisations pour les autres utilisateurs.
        • Les administrateurs disposent de toutes les autorisations pour tous les dossiers, quelles que soient les autorisations par défaut du dossier.

        Il existe certaines limites sur ce que les administrateurs peuvent faire, cependant :

        • Les administrateurs ne peuvent pas bloquer l'hôte.
        • Les administrateurs n'ont pas accès aux groupes de l'hôte (ou de tout autre administrateur).
5. Pour supprimer un utilisateur ou un Groupe, sélectionnez-les, puis sélectionnez .
6. Sélectionnez OK.

Lors de la définition des Autorisations, il existe deux Sets™ de hiérarchies à prendre en compte : les ensembles d'autorisations et les états d'autorisation.

• Un Set d’autorisations décrit comment un utilisateur a obtenu ses autorisations : Lui ont-elles été attribuées spécifiquement (autorisations individuelles) ? L’utilisateur les a-t-il obtenues en vertu de son appartenance à un certain Groupe (autorisations de groupe) ? Ou l’utilisateur a-t-il hérité des autorisations générales parce qu’aucune des deux conditions précédentes n’était remplie (autorisations générales) ?
• Un État d'autorisation décrit si l'utilisateur est autorisé à effectuer une certaine tâche (Autoriser) ou non (Refuser). Pour les utilisateurs individuels et les groupes, les états d'autorisation peuvent être spécifiquement sélectionnés (Explicite) ou laissés vides, ce qui les fera revenir à l'état d'autorisation correspondant pour le groupe Tout le monde (Hérité).

Les états d'autorisation fonctionnent au sein des ensembles Sets™ d'autorisations et n'entrent généralement en jeu que pour résoudre les conflits qui surviennent lorsqu'un utilisateur est membre de deux groupes ou plus ayant des autorisations conflictuelles (voir les exemples 4 et 5 ci-dessous pour plus d'illustrations). Il est généralement recommandé de ne pas ajouter de personnes à plusieurs Groupes, mais si cela est nécessaire, les hôtes et les administrateurs doivent se coordonner pour s'assurer que les autorisations appropriées sont accordées.

Hiérarchies

Les hiérarchies sont :

Sets d’autorisations

1. Les autorisations individuelles (c'est-à-dire celles configurées pour un utilisateur spécifique) ont une importance primordiale.
2. Les autorisations de groupe (c'est-à-dire celles configurées pour un Groupe que vous avez créé) ont une importance secondaire.
3. Les autorisations générales (c’est-à-dire celles définies pour le groupe par défaut Tout le monde) ont le moins d’importance.

États des autorisations

1. Un refus explicite (c'est-à-dire une autorisation spécifiquement définie sur Refuser) revêt une importance primordiale.
2. L’autorisation explicite (c’est-à-dire une autorisation spécifiquement définie sur Autoriser) a une importance secondaire.
3. L'état hérité (c'est-à-dire toute autorisation — qu'il s'agisse de refuser ou d'autoriser — héritée du groupe par défaut Tout le monde) a la moindre importance.

Exemples

Compte tenu de ces hiérarchies, voici quelques exemples qui illustrent la manière dont les autorisations réelles d'un utilisateur sont déterminées :

1. L'utilisateur Alice a configuré des autorisations individuelles, et l'autorisation Envoyer des invitations est définie sur Refuser. L'utilisateur Alice appartient également au Groupe A, et les autorisations pour Envoyer des invitations pour le Groupe A sont définies sur Autoriser. Alice ne pourra pas envoyer d'invitations au Projet.
   • Ses autorisations individuelles priment sur les autorisations du Groupe A.
2. L'utilisateur Bob a configuré des autorisations individuelles et l'autorisation d'envoyer des invitations est définie sur Autoriser. L’utilisateur Bob fait également partie du Groupe A et l’autorisation d’envoyer des invitations pour le Groupe A est définie sur Refuser. Bob pourra envoyer des invitations au Projet.
   • Ses autorisations individuelles priment sur les autorisations du Groupe A.
3. L’utilisateur Charlie dispose d’autorisations individuelles configurées et l’autorisation d’envoyer des invitations est définie sur Autoriser. L’utilisateur Charlie appartient également au groupe A et les autorisations d’envoyer des invitations pour le groupe A sont définies <blank> sur. L’autorisation d’envoyer des invitations pour le groupe Tout le monde est définie sur Refuser. Charlie pourra envoyer des invitations au Projet.
   • Ses autorisations individuelles priment sur les autorisations du Groupe A.
4. L’utilisateur Alice n’a pas d’autorisations individuelles configurées, mais elle fait partie du Groupe A qui a l’autorisation Envoyer des invitations définie sur Autoriser et elle fait également partie du Groupe B qui a l’autorisation Envoyer des invitations définie sur Refuser. Alice ne pourra pas envoyer d’invitations au Projet.
   • L'autorisation explicite de refus du Groupe B annule l'autorisation explicite d'octroi du Groupe A.
5. L'utilisateur Bob n'a pas d'autorisations individuelles configurées, mais il fait partie du Groupe A qui a l'autorisation Envoyer des invitations définie sur Autoriser et il fait partie du Groupe B qui a l'autorisation Envoyer des invitations définie <blank> sur. L'autorisation Envoyer des invitations pour le groupe Tout le monde est définie sur Refuser. Bob pourra envoyer des invitations au Projet.
   • L'autorisation explicite d'octroi du Groupe A annule l'autorisation de refus héritée du Groupe B.