关于上下文团队
一个上下文团队是一个应用程序上下文的成员列表。默认情况下，该上下文的所有成员都能够查看相应的团队。
团队成员是指上下文中分配的角色。最初，一个团队总是具有下列角色 (但也可具有其他角色)：
• 成员 - 使用此角色以授予用户对上下文中所有操作的常规访问权限。
• 访客 - 使用此角色以将用户限制为能够查看上下文中的所有操作但不能对其进行更改。
• 协作管理者 - 使用此角色可为用户提供共享应用程序上下文中的对象时所需的访问权限，并可使用“编辑访问控制”操作管理专用访问控制权限。
默认情况下，此角色下的用户会享有具备所有可共享对象类型“更改权限”的权利。借助此权限，用户可以
◦ 完成共享操作，例如，对其具有其他所需权限的对象执行“添加至项目”操作。
例如，要对内容存储在 Windchill 中的文档执行“添加至项目”/“PDM 检出”操作，用户必须对源对象具有“读取”、“下载”、“更改”和“修改”权限；对源上下文具有“读取”权限；对目标文件夹具有“读取”和“修改”权限；对对象的项目特定版本具有“创建”权限。
◦ 更改对对象的专用访问控制权限以授予其他用户他们原有的相同权限或权限的子集，前提是将“访问权限配置 (PDM)”安全首选项配置为允许修改权限。
例如，如果“协作管理员”对某个文档具有“完全控制 (全部)”权限，则他或她可以授予另一用户对该文档具有最高“完全控制 (全部)”的权限。
用户不会自动添加到此角色，除非在 Windchill 升级期间可进行选择。用户需要添加到此角色中或者必须具有适当的权限才能执行共享操作。有关向角色添加用户的详细信息，请参阅创建和编辑团队模板。
 |
用户不需要成为“协作管理员”也能共享对象或修改专用访问控制权限。拥有适当权限的任何用户都可执行这些操作。
|
• 上下文管理者角色 - 可用的上下文管理者角色如下所示：
◦ 项目上下文 - 项目经理
◦ 项目群上下文 - 项目群经理
◦ 产品上下文 - 产品经理
◦ 存储库上下文 - 存储库经理
对于负责管理上下文的用户，请使用上下文管理者角色。这包括管理团队以及上下文中的所有数据。
系统会自动将上下文管理者角色分配给上下文的创建者；但是，创建者可以将此角色分配给其他团队成员。不会向团队中的角色自动添加任何其他用户。
除了上下文管理者、“成员”、“访客”以及“协作管理员”角色外，将责任与角色关联并无明确方法；但是，您可以在应用程序上下文中创建一个文档，用它来标识每个团队角色或成员的责任。如果贵公司要采用工作流进程或更改进程来指导用户的活动，您可能需要查看在这些进程中所使用的角色，以决定您想要在上下文团队中加入哪些角色。有关角色和组的详细信息，请参阅角色和组。有关工作流进程或更改进程的详细信息，请分别参阅工作流模板管理和关于更改管理。
 |
您可以在创建上下文时为需要但未知的成员创建占位符。例如，如果您具有名为“设计者”的角色并且知道您需要三个设计者，但在项目创建时只确定了一个设计者，则可以通过使用虚构的电子邮件地址定义占位符来代表未知的设计者。一旦为这些成员指定了资源，就可用实际用户替换占位符用户。
|
如果用户通过“查找参与者”窗口中的“通过电子邮件发送邀请函”字段添加到组中，且未注册为 Windchill 用户，则待处理团队成员的电子邮件地址将显示在“成员”表的“角色/成员”列中。
同步团队和用户定义的组这一操作由系统自动完成，但通过在目录服务中使用第三方 LDAP 工具 (非 Windchill) 更新组来向用户定义组中添加新成员或从中删除成员的情况除外。有关详细信息，请参阅同步团队和用户定义的组。
如果定义的上下文团队包括共享团队，则在共享团队中定义的角色和成员将成为上下文团队中的角色和成员。请参阅关于共享团队。
相关主题