A propos des rôles et groupes

Un rôle relie les membres d'un contexte d'application aux informations et activités gérées dans ce contexte. Les rôles facilitent le regroupement de personnes ayant des tâches similaires dans le contexte d'une façon utile pour l'équipe. Lorsque plusieurs utilisateurs sont invités à devenir membres d'un contexte d'application, le responsable de contexte doit affecter au moins un rôle, tel que Concepteur ou Validateur, à chaque utilisateur. Plusieurs rôles peuvent être affectés aux membres d'un contexte. L'ensemble des rôles affectés à chaque membre est affiché dans le tableau Membres.

Bien que certains rôles et groupes soient affectés lors de la création des contextes d'organisation et d'application, des rôles supplémentaires peuvent être définis pour chaque contexte à partir du tableau Membres, si le contexte n'utilise pas d'équipe partagée ou si l'équipe partagée utilisée peut être étendue localement.

Le rôle de responsable de contexte est le seul autorisé à créer et organiser le contexte d'application, inviter ou supprimer des membres de l'équipe et gérer les opérations du contexte. Dans les contextes de projet ou de programme, un gestionnaire de contexte gère également les informations de suivi de projet ou de programme.

L'utilisateur qui crée le contexte reçoit automatiquement le rôle de responsable de contexte. Pour partager la gestion du contexte d'application, un responsable de contexte peut affecter d'autres membres à ce rôle. Les rôles disponibles pour le gestionnaire de contextes sont les suivants :

Le rôle Invité permet à une personne de visualiser le contexte d'application, sans pour autant être invité comme un membre. Les permissions s'appliquant aux participants affectés au rôle d'invité pour un contexte donné sont les suivantes :

L'accès aux informations d'un contexte d'application peut être contrôlé grâce aux rôles. Chaque rôle est associé à un groupe système portant le même nom que le rôle. En tant que responsable ou administrateur de contexte, vous pouvez définir des règles d'accès aux politiques pour chaque groupe système à l'aide de l'utilitaire Administration des politiques. En outre, en tant que propriétaire d'un objet, vous pouvez accorder ou retirer des permissions de contrôle d'accès pour l'objet à l'aide de l'action Modifier le contrôle d'accès. Par exemple, lorsqu'un nouveau fichier est chargé ou qu'un nouveau dossier ou article est créé, la personne qui crée l'objet est responsable de la définition de l'accès aux informations le concernant.

Pour plus d'informations sur les rôles disponibles dans chaque solution Windchill et sur les permissions de contrôle d'accès qui peuvent être définies, consultez la section Présentation du contrôle d'accès.

Les groupes sont utilisés pour gérer le contrôle d'accès aux informations, limiter la visibilité des actions, permettre une communication par e-mail et envoyer des invitations à des conférences. Par exemple, les participants à une conférence peuvent être invités à des conférences et des pages peuvent être envoyées par e-mail à chaque groupe.

Certains groupes système sont utilisés dans les équipes associées à un contexte, de même que des groupes définis par l'utilisateur peuvent être créés et conservés dans les contextes d'organisation et de site ou sur un serveur d'annuaire d'entreprise. Les groupes système sont utilisés pour gérer l'appartenance aux rôles d'équipe et sont conservés uniquement dans la base de données Windchill. Cette section décrit les groupes système utilisés dans les équipes. Pour plus d'informations sur les groupes définis par l'utilisateur pouvant être créés dans Windchill, consultez la section Groupes (organisations) ou Création d'un groupe.

Pour chaque rôle défini dans une équipe associée au contexte ou dans un modèle d'équipe, un groupe système correspondant, portant le même nom, est automatiquement créé. Par exemple, le groupe des rôles système du rôle Administrateur des modifications II est ADMINISTRATEUR DES MODIFICATIONS II et le groupe des rôles système du rôle de membre est MEMBRES. Les utilisateurs ajoutés à un rôle sont automatiquement ajoutés au groupe système correspondant. Le responsable de contexte peut ensuite créer des politiques d'accès pour les groupes système grâce à l'utilitaire Administration des politiques. Ces politiques sont appliquées à chaque fois que les rôles sont utilisés.

Les groupes système supplémentaires suivants ont été créés pour être utilisés dans des équipes associées à un contexte :

• Un groupe Membres de l'équipe comprend tous les membres de l'équipe dans le contexte d'application. Ce groupe est créé dans chaque contexte d'application. Windchill conserve ce groupe. Vous ne pouvez pas modifier manuellement les membres de ce groupe.

• Un ensemble de groupes système représente les organisations des membres de l'équipe associée au contexte. Chaque groupe comprend toutes les personnes d'une même organisation qui sont membres d'un même contexte d'application. Les groupes de l'organisation de l'équipe sont mis à jour automatiquement, à mesure que les membres de l'équipe sont ajoutés et supprimés. Lorsqu'un utilisateur d'une nouvelle organisation est ajouté à un contexte, le système crée automatiquement le groupe système correspondant aux membres de cette organisation. Chaque groupe porte le nom de l'organisation. Windchill conserve cet ensemble de groupes. Vous ne pouvez pas modifier manuellement les membres de cet ensemble de groupes.

Par exemple, supposons qu'un contexte d'application a été créé et que des personnes de l'entreprise A sont ajoutées à l'équipe associée au contexte en tant que membres des rôles disponibles dans l'équipe. Cette action crée les groupes système suivants :

Ensuite, des personnes de l'entreprise B sont invitées dans le contexte et le rejoignent. Tous les membres de l'entreprise B sont alors ajoutés au groupe Membres de l'équipe et un nouveau groupe Entreprise B est créé. Ce groupe comprend uniquement les personnes membres de l'équipe qui appartiennent à l'entreprise B.

Si des personnes sont ajoutées à une équipe via le rôle Invité, elles ne seront pas membres de l'équipe et ne seront pas ajoutées au groupe Membres de l'équipe ni à l'ensemble des groupes représentant les organisations des membres dans l'équipe associée au contexte. Etant donné que les utilisateurs du rôle d'invité ne font partie que d'un modèle d'équipe, les utilisateurs du rôle invité ne sont pas ajoutés automatiquement au groupe Membres de l'équipe.

En outre, vous pouvez utiliser les rôles dynamiques qui sont disponibles dans l'utilitaire Administration des politiques lors de la création des règles de contrôle d'accès dans les contextes de site et d'organisation. Les rôles dynamiques représentent les groupes des équipes associées au contexte et des organisations qui sont maintenus pour chaque équipe associée au contexte. Par exemple, le rôle Rôle de l'équipe associée au contexte : Ingénieur, disponible dans l'onglet Rôles, lors de la création d'une règle de politique d'accès, représente le groupe système d'ingénieurs associé aux équipes associées au contexte et aux équipes partagées. Les règles créées pour les rôles dynamiques sont héritées par les contextes enfant du contexte d'organisation dans lequel les règles ont été créées. Vous devez créer les règles dans un domaine qui est parent du domaine utilisé dans le contexte d'application. Pour plus d'informations sur l'utilisation des rôles dynamiques, consultez la section Utilisation des rôles dynamiques pour centraliser l'administration des règles de contrôle d'accès.