A propos des équipes associées au contexte
Une équipe associée au contexte est une liste de membres d'un contexte d'application. Par défaut, tous les membres du contexte peuvent visualiser l'équipe.
Les membres de l'équipe reçoivent des rôles dans le cadre du contexte. A l'origine, une équipe a toujours les rôles suivants (mais elle peut avoir des rôles supplémentaires) :
• Membres : utilisez ce rôle pour permettre aux utilisateurs d'avoir un accès général à toutes les actions du contexte.
• Invité : utilisez ce rôle pour limiter les utilisateurs à la possibilité de visualiser, sans qu'ils puissent modifier quoi que ce soit dans le contexte.
• Gestionnaire de collaborations : utilisez ce rôle pour fournir aux utilisateurs les droits d'accès nécessaires au partage d'objets dans les contextes d'application et à la gestion des droits de contrôle d'accès ad hoc à l'aide de l'action Modifier le contrôle d'accès.
Par défaut, les utilisateurs de ce rôle disposent des permissions de modification sur tous les types d'objets pouvant être partagés. Grâce à cette permission, les utilisateurs peuvent
◦ exécuter une action de partage, telle que Ajouter au projet, pour les objets sur lesquels ils disposent des permissions supplémentaires requises.
Par exemple, pour réaliser une action Ajouter au projet/Récupération PDM sur un document dont le contenu est stocké dans Windchill, un utilisateur doit disposer des permissions de lecture, de téléchargement, de modification sur l'objet source et doit pouvoir modifier les permissions de l'objet source. Il doit également posséder des permissions de lecture sur le contexte source, des permissions de lecture et de modification du dossier cible et de permissions de création sur la version spécifique au projet de l'objet.
◦ Modifier les permissions de contrôle d'accès sur un objet pour fournir à d'autres utilisateurs les mêmes permissions ou un sous-ensemble de ces permissions, à condition que la préférence de sécurité Configuration des permissions d'accès (PDM) soit configurée de sorte à autoriser la modification des permissions.
Par exemple, si un gestionnaire de collaborations dispose de la permission Contrôle total (tout) sur un document, il peut fournir à d'autres utilisateurs jusqu'à la permission Contrôle total (tout) sur le document.
Les utilisateurs ne sont pas ajoutés automatiquement à ce rôle, sauf éventuellement lors de la mise à niveau de Windchill. Un utilisateur doit être ajouté à ce rôle ou disposer des permissions appropriées pour exécuter les actions de partage. Pour en savoir plus sur l'affectation d'utilisateurs à des rôles, consultez la section Création et modification d'un modèle d'équipe.
 |
Un utilisateur n'a pas besoin d'être un gestionnaire de collaborations pour partager des objets ou modifier des permissions de contrôle d'accès ad hoc. Tout utilisateur disposant des permissions appropriées peut effectuer ces actions.
|
• Un rôle de responsable de contexte. Les rôles de responsable de contexte disponibles sont les suivants :
◦ Contexte de projet : chef de projet
◦ Contexte de programme : responsable de programme
◦ Contexte de produit : responsable produits
◦ Contexte de bibliothèque -- Gestionnaire de bibliothèque
Utilisez le rôle de responsable de contexte pour les utilisateurs responsables de la gestion du contexte. Ses responsabilités comprennent la gestion de l'équipe et de toutes les données du contexte.
Le rôle de responsable de contexte est automatiquement affecté au créateur du contexte. Ce dernier peut cependant réaffecter ce rôle à d'autres membres de l'équipe. Aucun autre utilisateur n'est ajouté automatiquement aux rôles de l'équipe.
En dehors des rôles Responsable de contexte, Membres, Invité et Gestionnaire de collaborations, les rôles ne sont pas associés à des responsabilités particulières. Toutefois, vous pouvez créer un document dans le contexte d'application qui définit les responsabilités de chacun des rôles ou membres de l'équipe. Si votre entreprise utilise des processus ou processus de modification pour diriger les activités des utilisateurs, vous pourriez vouloir consulter les rôles employés dans ces processus afin de déterminer quels rôles vous souhaitez inclure dans vos équipes de contexte. Pour plus d'informations concernant les rôles et les groupes, consultez la section Rôles et groupes. Pour plus d'informations sur le processus ou sur les processus de modification, consultez respectivement les sections Administration des modèles de processus et A propos de la gestion des modifications.
 |
Vous pouvez créer des repères pour les membres qui sont nécessaires mais encore inconnus lors de la création du contexte. Par exemple, supposons que vous avez un rôle appelé "concepteurs". Vous savez que vous avez besoin de trois concepteurs mais vous n'en avez défini qu'un au moment de la création du projet. Vous pouvez alors définir des repères à l'aide d'adresses électroniques fictives pour représenter les concepteurs inconnus. Dès que les ressources sont identifiées pour ces membres, vous pouvez remplacer l'utilisateur repère par l'utilisateur réel.
|
L'adresse électronique d'un membre de l'équipe en attente s'affiche dans la colonne Rôles/Membres du tableau Membres si l'utilisateur est ajouté à une équipe via le champ Invitation par e-mail de la fenêtre Rechercher un participant et n'est pas enregistré en tant qu'utilisateur Windchill.
La synchronisation des équipes à des groupes définis par l'utilisateur est désormais automatique, sauf si de nouveaux membres sont ajoutés à un groupe défini par l'utilisateur ou retirés de ce dernier lors de la mise à jour dudit groupe dans votre service d'annuaire à l'aide d'un outil LDAP tiers (autre que Windchill). Pour plus d'informations, consultez la section Synchronisation des équipes avec les groupes définis par l'utilisateur.
Si l'équipe de contexte inclut une équipe partagée, les rôles et membres définis dans l'équipe partagée deviennent des rôles et membres de l'équipe de contexte. Consultez la section A propos des équipes partagées.
Rubriques connexes