在策略管理实用程序中应用规则
必须针对所有生命周期阶段来创建适用于 PTC FlexPLM 对象的规则。PTC FlexPLM 不支持特定于生命周期状态的访问控制列表。针对特定生命周期状态创建的规则会导致不一致的结果，并且不受支持。
如果某个子类型 (或根类型) 将设置为可实例化 (使其无法在 PTC FlexPLM 中选择)，则必须将其添加到 wt.admin.hierarchyListAdditions.wt.access.PolicyAccessControlled 属性，以使其显示在策略管理实用程序中。
• 将条目添加到 site.xconf 文件并运行命令 xconfmanager -p。
• 条目必须遵循以下格式：
<AddToProperty
name="wt.admin.hierarchyListAdditions.wt.access.PolicyAccessControlled"
value="fully qualified class name"/>
例如：
<AddToProperty
name="wt.admin.hierarchyListAdditions.wt.access.PolicyAccessControlled"
value="com.lcs.wc.planning.FlexPlan"/>
PTC FlexPLM 中策略管理的要求比 Windchill 的“策略管理”实用程序允许的要求更加严格。
通用访问控制列表规则
这些规则对于 PTC FlexPLM 和 Windchill PDMLink 均成立。
• 显式授予或拒绝访问控制列表适用于类型及其所有子类型。
示例 1：
◦ “类型和属性管理”实用程序中的类型结构：
◦ “策略管理”实用程序中的访问规则：
在此示例中，将授予读取权限。如果这是为“颜色”类型创建的唯一规则，则 Retail 组的用户对“颜色”类型和 LCSColorSubtype1 都具有查看访问权 (因为 LCSColorSubtype1 从“颜色”类型中继承规则)。
• 如果将某个规则应用于给定承担者，并且该承担者是一个组，则规则适用于该组的所有成员。如果有一个子组 (作为组成员的组)，则组还适用于子组的所有成员，包括其下面的所有子组。
在示例 1 中，直接是 Retail 组成员或者是 Retail 组的子组 (是 Retail 的成员的组) 成员的所有用户，对于“颜色”类型及其子类型具有查看访问权。
• 如果没有为给定类型或其父项的任何特定创建、读取、更新或删除操作显式授予某个授予规则，则该授予规则被视为拒绝该访问。
在示例 1 中，仅授予读取权限。不会显式授予或拒绝创建、修改和删除。如果这是为“颜色”类型创建的唯一规则，则 Retail 组的用户对“颜色”类型和 LCSColorSubtype1 具有查看访问权。他们对任何“颜色”类型都没有创建、修改或删除访问权。
• 如果两个显式创建的规则解析为相同类型，则任何拒绝规则优先。显式拒绝规则始终覆盖显式授予规则。例如，对于“颜色”类型和 LCSColorSubtype1，则 Retail 组对“颜色”类型具有读取访问权。GroupC (是 Retail 组的成员) 被拒绝对 LCSColorSubtype1 的读取访问权。如果用户属于 GroupC，则用户被拒绝访问。
示例 2：
◦ 组和用户成员资格：Retail 组包含组 GroupA 和 GroupC。GroupA 以 userA 作为成员。GroupC 以 groupA 和 userC 作为成员。
◦ “类型和属性管理”实用程序中的类型结构：
◦ “策略管理”实用程序中的访问规则：
在示例 2 中，GroupC 已被显式授予了对“颜色”类型的查看访问权。还有一个规则可拒绝对 GroupA 成员的查看访问权。尽管 GroupA 的成员作为 GroupC 的成员被授予对“颜色”类型的访问权 (因为 GroupA 是 GroupC 的成员)，但这些成员仍被拒绝访问“颜色”类型。这是因为任何显式拒绝规则都将否决任何授予规则。GroupC 中不是 GroupA 的成员的任何其他用户都具有读取访问权。
对子类型的访问权
在 Windchill PDMLink 中，如果以下情况适用，则可以授予对子类型的访问权：
• 父项类型已被授予访问权，并且没有任何其他规则拒绝该访问权 (直接对子类型或者其任何父项)。
• 未对子类型的任何父项类型授予或拒绝任何特定访问权 (例如，空权限)，并且访问权显式授予子类型。
在 PTC FlexPLM 中，如果根类型已被授予访问权，并且没有针对从根类型到 (包括) 子类型的显式拒绝权限来移除给定用户的权限，则您具有对子类型的访问权。
• 如果您没有任何给定类型的各自特定创建、读取、更新或删除操作的访问权，则您对该类型的任何子类型没有该访问权。您必须具有所有父项类型的访问权才能访问子类型。
• 一旦应用了某个拒绝规则，该拒绝规则将拒绝您访问特定类型以及对其指定了该规则的类型的所有子类型。
• 如果父项类型具有显式拒绝，则对子类型的授予不会增加访问权，即使是父项类型的父项授予访问权。
示例 3：
• “类型和属性管理”实用程序中的类型结构：
• “策略管理”实用程序中的访问规则：
在示例 3 中，Retail 组的用户被显式授予了对“颜色”类型的查看访问权。他们被显式拒绝对 LCSColorSubtype1 查看访问权。因此，Retail 组的用户对“颜色”类型具有查看访问权，但对 LCSColorSubtype1 或 LCSColorSubtype2 没有查看访问权。
根类型中的访问权
一旦在根类型授予访问权，您便可以使用拒绝规则来进一步优化访问权。一旦已对给定类型拒绝了访问权 (应用于给定用户时)，所有子类型也将被拒绝访问权。
类型和组配置的示例：
此图在左侧包含部分类型结构。此图假定针对“服饰配件”和“鞋类”类型重复类型结构。
• 对于“根/服装/男士”类型，仅“男士服装”组的用户具有访问权。
• 对于“根/服装/女士”类型，仅“女士服装”组的用户具有访问权。
类型树具有 “服饰配件”和“鞋类”类型，与左侧图中未显示的“服装”为同代。这些与关联的组具有类似组规则。对于此示例，我们仅设置在图中可见的类型的权限，并且我们将仅设置读取权限。
要在 PTC FlexPLM 中完成此操作，有两个选项：
• 将根类型的权限授予需要访问树中所有类型的所有用户。创建相应的显式拒绝权限以限制对子类型的访问权，其中，用户或组应没有访问权。
◦ 创建一个规则，授予对根类型的 Retail 组的读取权限。这种授予随后应用于所有子类型。如果权限在此处停止，则 Retail 组的所有用户可访问所有类型。
◦ 创建一个规则，用于拒绝“服饰配件”组对“根/服装”类型的读取权限。
◦ 创建一个规则，用于拒绝“鞋类”组对“根/服装”类型的读取权限。
◦ 创建一个规则，用于拒绝“男士服装”组对“根/服装/女士”类型的读取权限。
◦ 创建一个规则，用于拒绝“女士服装”组对“根/服装/男士”类型的读取权限。
• 在根类型中对需要访问树中所有类型或子类型的所有用户创建授予规则。使用“反向拒绝”规则以减少能够访问每个相应子类型的用户数量。
◦ 创建一个规则，授予对根类型的 Retail 组的读取权限。这种授予随后应用于所有子类型。如果权限在此处停止，则 Retail 组的所有用户可访问所有类型。
◦ 创建一个规则，用于拒绝除“服装”组外所有用户对“根/服装”类型的访问权。
◦ 创建一个规则，用于拒绝除“男士服装”组外所有用户对“根/服装/男士”类型的访问权。
◦ 创建一个规则，用于拒绝除“女士服装”组外所有用户对“根/服装/女士”类型的访问权。
| • 这两个选项均以一个父项组开始，其中包含需要访问结构中任何类型的所有组。 ◦ 此示例使用 Retail 组，但并非严格需要此组。 ◦ 一旦为根授予了访问权，在每个子类型中，将通过拒绝规则来优化具有访问权的用户的列表。绝没有任何其他授予规则。 • 这两个选项均利用组的组织来最小化需要创建的规则数量。并不严格要求您做到这一点。 ◦ 创建规则时，只能选择一个承担者。创建或使用显式拒绝规则时，如果没有良好的用户组织，通过添加单个规则来管理策略会非常繁琐。 ◦ 在第一个选项中，“鞋类”组允许创建一个规则来拒绝对“鞋类”的访问权。如果此组尚不存在，则可能已创建了两个规则：一个规则用于对“男士鞋类”组显式拒绝访问权，另一个规则用于对“女士鞋类”组拒绝访问权。如果组织更少，则需要创建更多规则。 • 对于跨组的用户，这两个选项有所不同。 ◦ 第一个选项对特定组中的用户显式拒绝访问。如果某个用户在“男士服饰配件”和“男士服装”组中，并且对“男士服饰配件”组中的用户拒绝访问，则即使该用户在“男士服装”组中，也会对该用户拒绝访问。 ◦ 第二个选项对不在特定组中的用户拒绝访问。如果用户在该组中，则用户继续具有访问权。如果某个用户在“男士服饰配件”和“男士服装”组中，并且对除“男士服装”组外的所有组拒绝访问，则即使该用户在“男士服饰配件”组中，也不会对该用户拒绝访问。 |
显式拒绝示例
• 组和用户成员资格：
◦ Retail 组以 GroupA 和 GroupB 作为成员。
◦ GroupA 以 userA 作为成员。
◦ GroupB 以 userB 作为成员。
• “类型和属性管理”实用程序中的类型结构：
• “策略管理”实用程序中的访问规则：
在此示例中，Retail 组的用户 (userA 和 userB) 被授予颜色类型 (LCSColor) 的查看访问权。GroupA 已被显式拒绝对 LCSColorSubtype1 的查看访问权。UserB 可以查看“颜色”类型、LCSColorSubtype1 和 LCSColorSubtype2 的对象。UserA 可以查看“颜色”类型的对象，但不能查看 LCSColorSubtype1 和 LCSColorSubtype2 的任何对象。
反向拒绝示例
• 组和用户成员资格：
◦ Retail 组以 GroupA、GroupC 和 GroupD 作为成员。
◦ GroupA 以 userA 作为成员。
◦ GroupC 以 GroupA 和 userC 作为成员。
◦ GroupD 以 userD 作为成员。
• “类型和属性管理”实用程序中的类型结构：
• “策略管理”实用程序中的访问规则：
在此示例中，已经为 Retail 组 (包括子组) 中的所有用户授予了对“颜色”类型 (LCSColor) 的查看权限。此外，已经对不是 GroupC 的成员的所有用户拒绝了对 LCSColorSubtype1 的权限。这导致 userA、userC 和 userD 能够在“颜色”类型中查看颜色。由于 userD 不是 GroupC 的成员，因此 userD 被拒绝对 LCSColorSubtype1 的访问权，而 userA 和 userC 继续具有查看访问权。
针对 Retail 组创建访问控制列表
要对 PTC FlexPLM 中的所有用户授予或拒绝访问权，请针对 Retail 组创建访问控制列表 (因为所有 PTC FlexPLM 用户都必须是此组的成员)。
• 例如，如果要为 PTC FlexPLM 中的所有用户授予对颜色类型的读取权限，则要创建一个规则，用于为 Retail 组授予读取访问权。
• 如果不希望 PTC FlexPLM 中的所有用户都具有访问权，则要创建一个针对 Retail 的子组的规则。这确保被授予访问权的用户是 PTC FlexPLM 用户，但将用户集限制为恰当的用户。
例如，您具有一个称为 Color Users 的组，作为 Retail 组的成员。授予读取权限的访问控制列表将针对 Color Users 组。这仅允许这些用户查看任何“颜色”信息。
• 如果您希望授予对根类型的访问权，但还要确保任何其他规则提供的访问权都不能超过您的规则中显式规定的访问权，那么您需创建一个规则以授予您要授予的访问权，并创建另一个规则以对任何其他人拒绝访问。
例如，您可能具有一条规则，用于对 WTObject 的所有用户授予完全控制权。
| 这是一个示例，说明了您绝对不应进行的操作。这将使系统中的所有用户能够对未显式拒绝的所有内容具有完全访问权。 |
如果在此情况下，您希望创建一个规则，以确保仅“颜色”用户对颜色具有访问权，则您将创建两个规则。
◦ 第一个规则将确保授予始终存在，即使针对 WTObject 的规则已移除。因此，您将创建一个规则，以对 Color Users 组授予读取访问权。
◦ 此外，要确保没有任何其他用户可以访问“颜色”类型 (通过对所有规则的 WTObject 授予)，您要创建一个规则，以对除 Color Users 组外的所有用户拒绝读取访问权。
◦ 这些组合规则确保 Color Users 组之外的任何用户都不能访问“颜色”类型，无论授予了其他哪些访问权。
