Glossary Terms

Domains Windchill domains are administrative areas that are defined when your Windchill system is configured. A set of domains is established when Windchill is installed and the administrator can create additional domains if they are needed. Windchill domains are used to provide a way of generally grouping access to objects. For example, the administrator can create an access control policy rule for a specific domain that enables all users to view all documents that are associated with the domain. Another rule could allow a select group of users to modify the content of all documents associated with the domain and a third rule could allow all team members to download the content of all documents associated with the domain. When you create objects that are associated with a domain, you may not have the ability to pick the domain association. If you are allowed to select a domain when you create an object, work with your administrator to determine which domain to select. Unless you are directed to select a specific domain, the best practice is to allow Windchill to chose the domain for you. Note: Do not confuse Windchill domains with Internet domains. Internet domain names are used to allow easy access to information over the Internet. Policy Access Control Rules A policy access control rule is set for a specific domain and is a mapping between an object type and life cycle state, and sets of participants (users, groups, or organizations) and their associated permissions. For an object type and a specific state, a policy access control rule specifies rights of participants concerning access to objects of that type, in that state. For example, a policy access control rule might state that everyone in the Publications group has permission to read all objects of type WTDocument in the Engineering domain when the objects are in the Under Review state. Policy rules use domains to provide structure as to when the rules are applied. Some of the permissions set for specific domains are loaded when your Windchill system was installed and others can be set by your administrator. Administrators use the Policy Administrator to manage policy access control rules. Policy rules cannot be changed through the Manage Security action. Policy access control rules apply to all objects of a specific type instead of to a specific object, as is the case with ad hoc access control rules.

Ad Hoc Access Control Rules An ad hoc access control rule is a rule granting access control permissions to a participant on a specific object.

Objects An object is a generic name for business data that is added to and managed in the Windchill system. Depending on the Windchill system you have installed, you will be working with different business objects. To obtain information about the main objects that appear in the different Windchill solutions, see About Objects in the Folder Management help. A folder is another object that you can use in all Windchill solutions to help organize the business objects that you create through your Windchill system. The folder object provides the same functionality as a folder on your PC, allowing you to group your parts, documents and other business objects according to your sites business practices. Context A context is a generic name for the defined projects, programs, products, or libraries within which users work. For example, if a user navigates to a folder within the Bike Design project and creates a new document, that document is managed in the context of the Bike Design project. The context provides the framework from which user actions are executed. Each context can establish the following: The context structure, which includes the default domains and folders

The default forum topics and notebook folders

Context participation, which includes the available roles, teams, and groups

Default access control policies

Data types, templates, and rules

Default life cycle and workflow templates

Project, program, product, and library contexts are known as application contexts. The other contexts available to administrators are the site and organization contexts. The site context is created when your Windchill solution is installed. When an organization context is created, an organization administrator is defined and the administrator decides who can create application contexts.

Participant A participant can be any user, group, or organization that is defined in the system and is accessible through the interface that allows you to search for participants. You can populate an access table using the View drop-down list on the table. One of the options in this list is Team Access. For details on this and other options in the list, see Access Table when working with single objects and Access Modifications Table when working with multiple objects. To search for individual users, groups, or organizations to add to the table, click the find participant icon. The Find Participant window opens. For help on finding participants, click the help icon on this window.

Permissions Permissions represent the operations that can be performed on an object. When your Windchill system is configured, an administrator establishes the permissions a specific participant (user, group, or organization) is granted or denied for types of objects that are created within a domain. When using your Windchill system, you can also establish a unique set of permissions for a specific object using the Modify Access step when you create a folder or share an object, or using the Manage Security action after the object has been created. The following table lists the access permissions that are available in your system and describes the possible rights that are granted or denied. Note: An administrator can limit the set of permissions that are available, so you may not see all of the permissions described in this table. Access Permission Rights Permi ssion Description

Full control. A user, group, or organization granted the Full Control (All) Full permission is granted all permissions currently defined and any that might be Contr defined in the future. Therefore, if new permission types are defined, you do ol (All) not have to write rules that specifically grant them to users, groups, or organizations with full control access. The right to know the existence of an object and to view the object and its attributes. Additionally, if the object has content, you can view an objects content information such as the file path to a local file or the location of external storage. This permission does not allow you to view the actual contents of the file.

Read

The right to download local files that are the primary content or are Downl attachments of an object. This right is applicable to objects with content, such oad as documents or drawings. The right to change the attributes of an object, as well as other characteristics that are part of the object definition but are not controlled by the Modify Content or Modify Identity permissions. For versioned objects, a user must have the Modify permission on the latest iteration of each version of a target object to update the attributes common to all versions that are not part of the objects identity. Modify permission on a version of a target object is required to modify that versions attributes. The right to add, replace, and delete content as well as to modify content information. Content can be a local file, URL, or external storage for the primary content and attachments of an object.

Modif y

Modif y Conte nt

Modif y For a part, this subset includes the part number and the organization identifier Identit (such as cage code) of the part, but not part name (which is often treated as a y short description). For a folder, the attributes include the folder name. Creat e By Move Creat e The right to move an object into an administrative domain.

The right to modify a subset of the attributes that determine the identity of an object.

The right to create an object. The right of a user to perform a set state operation where a state transition has been defined to allow the transition from the current life cycle state to the new state. Note: To perform a set state operation, a user must have the Set State permission and there must be a valid state transition defined between the current state and the desired state. If there is no transition defined, the user must have the Administrative permission to perform the operation. The right to revise an object. Revising creates a new version of the object at the same level as the original in the version tree. For example, you can create revision B from revision A.

Set State

Revis e

New View The right to create a version for a specific view. Versio n Chan ge The right to move an object out of a Windchill domain. Domai n Chan ge Conte xt

The right to move an object out of a context.

Delete The right to delete an object. Admin The right to perform certain administrative tasks. (For example, an istrativ administrator would have the right to undo another users checkout or set an e object to an arbitrary life cycle state.) Chan ge The right to change the ad hoc permissions that others have. Users, groups, or organizations granted the Change Permissions permission are allowed to

Permi change the ad hoc permissions of others to the permissions they themselves ssions have or to a subset of the permissions they have. Note: In addition to having the permissions required for an operation, users are required to have Read permission on any object displayed in the user interface while they are performing the operation. For example, to navigate to an object that is contained in a folder, users must have Read permission on the folder as well as the object in the folder.