在访问控制规则中使用动态角色
动态角色代表针对分配至上下文团队和共享团队中团队成员的角色创建的系统组。系统组在某个应用程序上下文中创建，代表在上下文团队中拥有成员的组织。
可为访问控制策略选择动态角色：
• 在站点上下文中，如果使用“策略管理”实用程序创建访问控制规则，则动态角色可用。这些动态角色包括在 wt.project.RoleRB.rbInfo 文件中定义的各个角色的上下文团队角色。在站点上下文界面中，您无法创建其他上下文团队角色；但是作为自定义的一部分，您可以更改 wt.project.RoleRB.rbInfo 文件的内容。
关于修改 .rbInfo 文件内容的详细信息，请参阅 Best Practices for Customizing Files Supplied by PTC (《PTC 提供的自定义文件的最佳实践》)。
• 在组织上下文中，如果使用“策略管理”实用程序创建访问控制规则，则动态角色可用。这些动态角色包括在给定组织上下文的“角色”表中设置为可见的角色的上下文团队角色。
在给定组织上下文的“角色”表格中，可见角色的初始设置继承自站点上下文。在组织上下文中，组织管理员可以添加、删除、显示及隐藏“角色”表格中显示的上下文团队角色。因此，这些角色可管理从组织上下文启动“策略管理”实用程序时显示的上下文团队角色集。
有关详细信息，请参阅#PolicyAdminDynamicRolesAbout/ExampleUser。
• 在站点上下文和组织上下文中，动态角色包含代表可在应用程序上下文中创建的系统组的组织角色。组织角色代表在上下文团队中拥有成员的组织。创建访问控制规则时，可使用对其具有访问权限的组织的组织角色。组织角色为自动创建；您无法创建其他组织角色。
有关详细信息，请参阅#PolicyAdminDynamicRolesAbout/ExampleWC。
• 在应用程序上下文中，使用“策略管理”实用程序创建访问控制规则时可用的动态角色包括“团队”页面上“成员”表中显示的上下文团队角色。从应用程序上下文中创建访问控制规则时，也可使用包含组织角色的动态角色。这些组织角色代表针对在上下文团队中拥有成员的各个组织，在其上下文中创建的系统组。在这些组织角色中，可使用对其具有访问权限的组织的组织角色。
使用在站点上下文和组织上下文中创建的动态角色来创建一般访问控制规则。这些规则可由以特定角色或从特定组织添加到团队的所有用户的应用程序上下文继承。
 |
为动态角色创建的访问控制规则的适用对象仅为属于驻留在应用程序上下文中的域。这是因为角色只与上下文团队结合使用。站点上下文和组织上下文没有关联的上下文团队。因此，针对动态角色创建的规则并不适用于这些上下文域中的对象。
|
示例：用户创建的角色
假定您有一组为组织编写全部规范文档的人员。您想要授予这组人员对所有文档的读取、下载、修改内容、修改、通过移动创建以及创建的权限。要为演示组织完成此项任务，可以执行以下操作：
1. 在“演示组织”上下文的“角色”表格中创建一个新的“规范编写者”角色。
2. 从“演示组织”上下文的“实用程序”页面启动“策略管理”实用程序。
3. 从“域”窗格中选择“默认”域。
4. 从“访问控制规则”选项卡中单击“创建新的访问控制规则”图标 
。
。5. 在“新建访问控制规则”窗口中，选择以下项：
字段 | 要选择的值 | ||
|---|---|---|---|
“类型” | 选择“文档”。 | ||
“状态” | 选择“全部”。 | ||
“参与者” | 在“参与者”字段中，搜索 Spec Writer。Spec Writer (Context Team Role - Demo Organization) 将显示在“参与者”字段中。 | ||
“权限” | 选择“授予”列中的“读取”、“下载”、“修改”、“修改内容”、“通过移动创建”和“创建”。
|
6. 单击“确定”创建规则。
现在，“规范编写者”动态角色的规则即在 /Default 域中创建，该域与“演示组织”上下文关联。所有 /Default 域的派生域均继承此规则。默认情况下，派生域包含在创建非专用应用程序上下文和共享团队时使用的 PDM、项目和共享团队域。因此，对于任意拥有使用“规范编写者”角色的团队的应用程序上下文和为非专用应用程序上下文创建或作为共享团队创建的应用程序上下文，其中的 /Default 域将自动继承“规范编写者”访问控制规则。
在一些站点和组织上下文中，会将动态角色选定为参与者，在这种上下文中创建和管理访问控制规则时将有助于访问控制规则的集中管理。在应用程序上下文内，动态角色参与者被视为与相应上下文团队角色和组织角色相关联的系统组。如果同时存在上下文团队系统组的访问控制规则集和相应动态角色的访问控制规则集，则在确定某特定域内特定类型和状态的策略访问控制列表 (ACL) 时，将合并这两组规则。例如，假定：
• “规范编写者”动态角色的访问控制规则已按前面示例所述的方法创建。
• 在“演示组织”下创建了 Super Bike 项目，该项目的访问级别并非默认的“仅项目成员”，并使用标准 /Default 域。/Default 域的域分级结构包括 /Default 域，作为父项与“规范编写者”动态角色的访问控制规则创建位置处“演示组织”关联。
• “规范编写者”角色已添加到 Super Bike 项目中。
为 Super Bike 项目中的“规范编写者”系统组生成的 ACL 包括通过策略规则 (这些策略规则为“演示组织”上下文中的“规范编写者”动态角色而创建) 授予的权限。“规范编写者”系统组还可以拥有通过 Super Bike 项目创建的其他策略规则和专用规则。如果存在其他策略规则，则所有策略规则 (包括为“规范编写者”动态角色设置的规则) 将合并在一起。有关域和域分级结构的详细信息，请参阅管理域及策略。
| | 要有效地使用在站点和组织上下文中为动态角色创建的访问控制规则，您应回顾用于创建上下文的组织和应用程序上下文模板中的访问控制规则集。确定应对这些模板进行哪些更改，以使模板中动态角色的规则集不会重复。您可以加载示例动态角色模板，这些模板为使用组织模板的动态角色设置了许多访问控制规则。这些规则随后将用于通过示例动态角色产品、存储库和项目模板创建的应用程序上下文中。有关动态角色模版示例的详细信息，请参阅使用动态角色。 |
示例：Windchill 创建的组织角色
假定您有两个组织 -“销售”和“制造”。您还有两种产品 -“遮阳伞”和“运动伞”。您已为六位用户划分组织和产品，如下表所示：
用户 | 组织 | 产品 |
|---|---|---|
Pat | 销售 | 运动伞 |
Paul | 销售 | 运动伞 |
Pam | 销售 | 遮阳伞 |
Dawn | 制造 | 遮阳伞 |
Dave | 制造 | 遮阳伞 |
Debbie | 制造 | 运动伞 |
Windchill 将为“运动伞”产品创建以下系统组和相应的组织角色：
组 | 成员 | 组织角色 |
|---|---|---|
销售 | Pat、Paul | 销售 |
制造 | Debbie | 制造 |
Windchill 根据“遮阳伞”产品的组织角色创建以下系统组：
组 | 成员 | 组织角色 |
|---|---|---|
销售 | Pam | 销售 |
制造 | Dawn、Dave | 制造 |
您在站点级别创建策略访问控制规则，向所有具有“制造”动态角色的用户授予对部件对象的“修改”权限。此规则由“遮阳伞”产品部件所在的域继承。因此，访问“遮阳伞”产品中的部件时，站点级别的规则将应用于 Dawn 和 Dave，因为他们是组织中“制造”系统组的成员。类似地，访问“运动伞”产品中的部件时，站点级别的规则将应用于 Debbie。如果也将 Dave 添加为“运动伞”产品的团队成员，则会针对该产品中的部件对其应用规则，因为他还与 Debbie 一起具有“制造”动态角色。
相关主题