|
Pour les vastes exigences de permission, envisagez d'utiliser des participants dissociés des contextes. Cela maintient l'équipe à un niveau optimal et réduit l'incidence sur les ressources de production du système. Lorsque les besoins en matière de permissions varient selon les contextes, utilisez des participants associés aux contextes.
|
Efficacité des ressources système
|
|
Cas les mieux appropriés
|
Lorsque les exigences de permissions de certains groupes de participants ne changent pas d'un contexte d'application à l'autre.
|
Utilisation
|
Les participants ne doivent pas être ajoutés à l'équipe. Il convient de leur accorder les permissions nécessaires via des règles de contrôle d'accès.
|
Exemples
|
Exemple 1
L'ensemble d'une organisation doit disposer d'un accès en lecture aux types de données spécifiques de chaque produit public dans l'organisation. Dans ce cas, une option pourrait consister à ajouter tous les utilisateurs de l'organisation au rôle d'invité dans chaque produit. Il s'agit d'une approche nécessitant un traitement intensif. Vous pouvez plutôt accorder aux utilisateurs un accès en lecture à des types d'objet spécifiques dans un domaine d'administration approprié, tel qu'un domaine d'organisation, par défaut ou PDM, via des règles d'accès.
Exemple 2
Un groupe d'utilisateurs particulier exécute les fonctions de validation de la conformité dans chaque contexte d'application. L'établissement d'un rôle de validation de la conformité et l'ajout des mêmes utilisateurs à ce rôle dans chaque contexte d'application induisent des coûts indirects inutiles. Au lieu de cela, il est possible d'octroyer les permissions nécessaires au groupe d'utilisateurs par le biais de règles d'accès pour un groupe défini par l'utilisateur de validation de la conformité, au sein d'un domaine d'administration approprié, tel que le domaine / (Root) du site.
|
Remarques supplémentaires
|
Pour les utilisateurs qui ne sont pas membres de l'équipe associée au contexte d'application, les contextes d'application ne sont pas répertoriés dans les pages Produit, Bibliothèque, Programme ou Liste de projets de l'interface utilisateur. Toutefois, les utilisateurs peuvent les rechercher. S'ils disposent des permissions appropriées, ils trouveront les contextes d'application. Les contextes d'application sont alors chargés dans les listes Accédés récemment du navigateur, où ils peuvent être utilisés ultérieurement.
Si ces utilisateurs doivent accéder à des actions qui ne sont pas automatiquement visibles aux non-membres de l'équipe, les paramètres de l'option Configurer les actions des rôles dans l'équipe peuvent être utilisés pour rendre de telles actions visibles pour les non-membres de l'équipe. Ces règles peuvent être automatiquement fournies à des nouveaux contextes via des modèles de contexte. Il se peut que certaines fonctionnalités, comme la participation aux processus, doivent également être configurées différemment pour les utilisateurs qui ne sont pas membres de l'équipe.
Les règles d'accès nécessaires pour que ces utilisateurs accèdent à différents types de données dans le contexte d'application peuvent varier au cas par cas. Ces permissions doivent être identifiées et accordées de façon appropriée.
|
Autres informations
|
Consultez la rubrique Gestion de l'accès aux données par l'intermédiaire des règles de contrôle d'accès.
|
Efficacité des ressources système
|
|
Cas les mieux appropriés
|
• Les participants nécessitent un accès aux objets résidant dans un contexte d'application en fonction de leur rôle dans le contexte.
• La même structure d'équipe peut être appliquée à plusieurs contextes d'application similaires avec peu ou pas de modification.
• Les mêmes utilisateurs ou groupes ont les mêmes rôles dans tous ces contextes d'application.
• L'équipe peut être étendue localement pour répondre à des besoins supplémentaires (consultez la section "Remarques supplémentaires" ci-dessous).
|
Utilisation
|
• Les équipes partagées sont souvent utilisées comme équipes de bibliothèque en raison de la nature générique des permissions à accorder aux utilisateurs.
• Dans d'autres cas, vous pouvez créer plusieurs équipes partagées pour répondre aux besoins de différents ensembles de produits et de projets.
|
Remarques supplémentaires
|
Les équipes partagées sont très efficaces lorsqu'elles ne sont pas étendues localement. L'extension locale de l'équipe crée une instance d'équipe locale, ce qui réduit certains des avantages en termes de performances que l'équipe partagée est censée fournir. En fonction de l'extension de l'équipe partagée dans chaque équipe locale, le véritable avantage lié à l'équipe partagée peut ne pas être atteint du tout.
|
Autres informations
|
Consultez la rubrique Gestion de l'accès aux données par l'intermédiaire de l'appartenance à une équipe.
|
Efficacité des ressources système
|
|
Cas les mieux appropriés
|
• Les participants nécessitent un accès aux objets résidant dans un contexte d'application en fonction de leur rôle dans le contexte.
• La structure d'équipe est propre à chaque contexte d'application.
• Les participants qui opèrent dans les rôles de l'équipe sont propres à chaque contexte d'application.
|
Utilisation
|
• Créez de larges regroupements d'utilisateurs en fonction de leurs responsabilités.
• Ajoutez les groupes à des rôles spécifiques de l'équipe.
• Ne créez pas de regroupements d'utilisateurs uniques pour chaque contexte. Pensez aux groupes d'utilisateurs réutilisables.
|
Remarques supplémentaires
|
Dans l'idéal, il convient de maintenir un nombre idéal de participants dans l'équipe locale.
|
Autres informations
|
Consultez la rubrique Gestion de l'accès aux données par l'intermédiaire de l'appartenance à une équipe.
|
Pratique de conception d'équipe inefficace
|
Points faibles
|
Bonne pratique
|
---|---|---|
Ajout de tous les utilisateurs de l'organisation au rôle d'invité (ou à tout autre rôle), dans chaque équipe, pour accorder la permission de lecture sur les données de contexte d'application.
|
Des structures d'équipe de très grande envergure imposent une forte demande sur les ressources système.
|
Fournissez des permissions d'accès de base à l'aide de règles de politique. Maintenez un nombre idéal d'utilisateurs devant être directement associés à une équipe.
|
Création d'un contrôle très précis des permissions par le biais de centaines de rôles pour chaque équipe.
|
Des structures d'équipe de très grande envergure imposent une forte demande sur les ressources système.
|
N'oubliez pas les concessions en termes de performances liées à la définition de nombreux rôles spécialisés. Maintenez un nombre idéal de rôles dans une équipe.
|
Considérons l'utilisation des modèles de produit ou de bibliothèque pour définir les règles de contrôle d'accès globales à créer pour les rôles d'équipe de l'ensemble des produits ou des bibliothèques.
|
Cela entraîne une duplication inutile, dans une configuration où les mêmes règles de contrôle d'accès sont créées pour un même rôle dans chaque produit.
|
Dans la mesure du possible, créez des règles de contrôle d'accès pour des rôles dynamiques au niveau Organisation au lieu de les dupliquer dans chaque contexte d'application. Pour plus d'informations, consultez la rubrique Utilisation de rôles dynamiques dans les règles de contrôle d'accès.
|
Des groupes d'utilisateurs uniques sont créés sur une base ad hoc pour les affectations de rôles dans les produits. Les groupes ne sont pas réutilisés et sont propres à un seul produit.
|
Cela peut entraîner une configuration dans laquelle de nombreux groupes d'utilisateurs présentent des participants identiques. Cela complique la maintenance des groupes d'utilisateurs et surcharge le LDAP.
|
Organisez les utilisateurs en groupes d'utilisateurs réutilisables au lieu de créer des groupes d'utilisateurs uniques pour chaque contexte. De même, associez directement des utilisateurs à des équipes au lieu de créer des groupes d'utilisateurs et de les associer à des rôles. La seconde méthode n'est pas aussi efficace que la première.
|