the following diagram. (Depending on the template you use, other domains can also be created in the organization and project contexts.) The diagram shows the Site, Org1, and Project1 contexts and domains:

Setting Up User Access to Data

You can determine which sets of users have access to the data in the context by setting access control rules in the domains associated with the context where the data resides. You can also establish the set of access control permissions users can view and edit when they manage the security of individual objects from within an application context.

Use the Policy Administration utility to create policy rules. For details on domain inheritance and setting policy rules, see Administering Domains and Policies on page 85 .

Use the Preference Management utility to establish the set of permissions users can view and edit. For details, see the Access Control chapter of the PTC Windchill Specialized Administration Guide.

Administration Overview

43

The Team link that is available in each context allows you to set up the role and role memberships; these can be used as the system groups against which the access control rules are set, as described in Managing Access to Data through Team Memberships on page 44 .

Use the Participant Administration utility to update users who have changed in your user directory service or create and update user-defined groups at the organization level that can be used as team members. For additional information about managing users, user-defined groups, and organizations, see Participants

(Users, Groups, and Organizations) on page 251 .

Additionally, you can limit the visibility of the actions in the user interface for users, user-defined groups, and organizations. For more information, see Profile Management on page 290 .

Managing Access to Data through Team

Memberships

Another aspect of managing user access to data can be found in managing who becomes a member of an application context. The context team associated with a product, library, project, or program establishes which users are members of a specific application context. A context team can be made up of the following teams:

•A shared team that is established by the site or organization administrator (or by others given the rights to create shared teams) in the context of an organization and selected when creating the application context.

•A local team that is established by the application context manager as part of creating and managing the application context.

•Both a shared team and a local team.

Team members are added to a shared team according to their established role in multiple application contexts. For example, you could have a group of engineers who fill the Design Engineer role for many of the products or projects managed by your organization. This user-defined group could then be added to a shared team that is then selected when the application context is created.

Team members are added to a local team according to their role in a specific product, library, program, or project. For example, you could have an individual who will be in the Reviewer role for only a specific product or project. Then, this individual could be added to the local team for that product or project. The initial roles that are available for shared and local teams are determined when the teams are created; however, additional roles can be added.

For each role used in a context team there is a corresponding system group created that administrators can use to create access control rules for the members assigned

to the role. The Team link under Products , Libraries , Programs , or

44	PTC Windchill® Basic Administration Guide