|
对于广泛的权限需求,请考虑使用独立于上下文的参与者。这将使团队大小保持到最佳水平并减少对系统处理资源的影响。对于不同上下文之间有差异的权限需求,请使用特定于上下文的参与者。
|
系统资源效率
|
|
最适合的情况
|
其中,特定参与者组的权限需求不会因为应用程序上下文的不同而发生更改。
|
使用方式
|
根本不应将参与者添加到团队中。相反,应通过访问控制规则授予其必要权限。
|
示例
|
示例 1
整个组织需要对组织内每个公用产品中特定数据类型的“读取”权限。在这种情况下,系统可能已经提供了一种方案,将组织中的所有用户添加至每个产品的“访客”角色中。这是一种处理能力要求较高的方法。相反,用户可以通过访问策略规则向适当的管理域 (例如组织的 /Default/PDM 域) 中的特定对象类型提供“读取”权限。
示例 2
一组特定用户在每个应用程序上下文中执行“合规性审阅”功能。建立“合规性审阅”角色并将相同用户添加到每个应用程序上下文的该角色上将增加不必要的开销。相反,用户组可通过访问策略规则为适当管理域 (例如 Site’s / (Root) 域) 中的“合规性审阅”用户定义组提供必要权限。
|
其他注意事项
|
对于不是应用程序上下文团队成员的用户,应用程序上下文将不会在用户界面的“产品”、“存储库”、“项目群”或“项目列表”页面中列出。但是,用户可以搜索它们。如果用户具有相应权限,则会找到这些应用程序上下文。访问过的应用程序上下文将加载到导航器中的最近访问列表中,并且可在此列表中找到以供后续使用。
如果此类用户需要访问对非团队成员并非自动可见的操作,则可使用团队上“配置角色的操作”设置使此类操作对非团队成员可见。此类规则可能会通过上下文模板自动提供给新上下文。某些功能,例如参与工作流,可能还需要为非团队成员用户进行不同的设置。
此类用户导航到应用程序上下文中不同类型数据所需的访问策略规则可能会因案例而异。应标识出那些权限,并相应地进行授权。
|
详细信息
|
请参阅通过访问控制规则管理对数据的访问。
|
系统资源效率
|
|
最适合的情况
|
• 参与者需要基于其在上下文中的角色访问驻留在应用程序上下文中的对象。
• 可将相同的团队结构应用于大量相似的应用程序上下文,而几乎无需或根本不必更改的情况。
• 在所有那些应用程序上下文中相同角色均具有相同用户或组功能的情况。
• 可进行本地扩展以满足其他需求 (请参阅下面的附加注意事项)。
|
使用方式
|
• 由于要向用户提供的权限具有通用特性,因此共享团队经常用于“存储库”团队。
• 在其他情况下,可能会创建多个共享团队以满足不同系列的“产品”和“项目”。
|
其他注意事项
|
未进行本地扩展时共享团队是最高效的。本地扩展团队会创建一个本地团队实例,这样就降低了共享团队可能具备的某些性能优势。根据共享团队在每个本地团队中修改的广泛程度,共享团队的真正优势可能根本无法实现。
|
详细信息
|
请参阅通过组成员资格管理对数据的访问。
|
系统资源效率
|
|
最适合的情况
|
• 参与者需要基于其在上下文中的角色访问驻留在应用程序上下文中的对象。
• 团队结构特定于每个应用程序上下文。
• 在团队角色中行使职责的参与者特定于每个应用程序上下文。
|
使用方式
|
• 根据职责,创建广泛的用户组。
• 将组添加到团队中的特定角色。
• 请勿为每个单独上下文创建唯一用户组。请考虑使用可重用的用户组。
|
其他注意事项
|
理想情况下,需要包括在本地团队中的参与者数应保持在最佳数量。
|
详细信息
|
请参阅通过组成员资格管理对数据的访问。
|
低效的团队设计实践
|
弊端
|
最佳业务实践
|
---|---|---|
将组织中的每个用户添加到每个团队中的“访客”角色 (或任何其他角色),以授予对应用程序上下文数据的“读取”权限。
|
团队结构过于庞大,催生出大量的系统资源需求。
|
使用策略规则提供基本访问权限。将需要与团队直接关联的用户数保持为最佳数量。
|
通过为每个团队创建数以百计的角色来实现对权限的精确控制。
|
团队结构过于庞大,催生出大量的系统资源需求。
|
请记住在定义多个专用角色时的性能取舍。将团队中的角色数保持为最佳数量。
|
使用产品或存储库模板来指定应该在所有产品或存储库中为团队角色创建的相同策略访问控制规则。
|
这会导致不必要的重复,即会为每个产品中的相同角色创建相同的策略访问控制规则。
|
如有可能,请在“组织”级别为动态角色创建策略访问控制规则,而不是在每个应用程序上下文中重复它们。有关详细信息,请参阅在访问控制规则中使用动态角色。
|
在专用基础上为产品中的角色分配创建唯一的用户组。组不可重新使用,且特定于单个产品。
|
会产生多个具有类似参与者成员资格的用户组。这会使用户组的维护变得复杂,并导致 LDAP 过载。
|
将用户组织到可重用的用户组中,而无需为每个上下文创建唯一用户组。或者,将用户直接与团队关联,而不是创建用户组并将那些组与角色关联。第二种方法不如第一种高效。
|