Solution
Modify the roleaccessprefs.xml file (and associated files as needed).
Prerequisite knowledge
To achieve this objective, you need to have an understanding of the following:
• The behavior of user roles in Windchill
• The administration of ad hoc access control policies in Windchill
• The actions framework in the Windchill client architecture
• The navigation framework in the Windchill client architecture
• The management of XML file customizations
• The management of resource file customizations
Solution Elements
|
Element
|
Type
|
Description
|
|
*actions.xml
|
XML
|
Files where actions and other UI components are defined. Actions are optionally given a uicomponent value. Actions.xml is located in <Windchill>/codebase/config/actions along with other *actions.xml files.
|
|
Roleaccessprefs.xml
|
XML
|
File for assigning default visibility to UI components. Setting items in this file can make them not appear at all for the site or containers. Whether or not the container manager can override the default value can also be changed here. Located in <Windchill>/codebase.
|
|
RoleAccessResource.java
|
java
|
Defines the labels to provide in the Uis for the actions or UI components. Located in <Windchill>/src/com/ptc/netmar kets/roleAccess/.
|
In actions.xml (and all *actions.xml files), an action can be assigned a uicomponent attribute value. The uicomponent attribute provides a name for a UI component that can be referenced from the roleaccessprefs.xml and roleAccessResource.java files. Multiple actions can use the same uicomponent value; this provides the ability to manage those actions as a single UI component. If an action does not have a uicomponent, then the action “name” can be used to reference it as a UI component instead. However, in this case it cannot be grouped with other actions into a single UI component.
The roleaccessprefs.xml file consists of a <uics> element containing several elements (or sections) that correspond to the primary tabs in the
Windchill user interface. For example, the <project> section corresponds to the Project tab. Each section contains zero or more <uic> elements, each representing a UI component whose visibility within that tab can be administered. Each UI component, specified with the “name” attribute of the <uic> element, can appear in one or more sections. This allows the default visibility settings for that UI component to be assigned independently for different tabs.
The roleaccessprefs.xml file applies to the UI component lists for visibility administration based both on profiles (at the site and organization levels) and on roles (at the container levels). However, the <global> section applies only to visibility administration using profiles. If a UI component is not tied to a specific tab (such as is the case with the Search link in the Windchill UI header) or the UI component is a first-level tab itself, it must be listed in the <global> section of roleaccessprefs.xml.
Each UI component must have an entry in roleAccessResource.java that provides a user-friendly label for that UI component. These labels are used for the UI components in the lists that are presented to the administrator when configuring visibility. In this file the resource entry “constant” identifies the UI component; it must match either the uicomponent from the action definition or the action name if the action has no uicomponent. The resource entry “value” provides the user-friendly label.
|
|
Your UI component label should be a verb phrase. If your action/UI component name is not already a verb phrase, place 'View' in front, for example "View Team Page."
|
Procedure - Making an Action Available to Visibility Administration
In this example, you provide the administrator with the ability to manage the visibility of the Create Folders action in the Project, Program, Product, and Library tabs.
|
|
This example assumes that the Create Folders action is not already available for role-based visibility management; in the actual product, it is available out of the box.
|
1. Add a new <uic> to the roleaccessprefs.xml under the sections <project>, <program>, <product>, and <library>:
<uic name="PROJECT_CREATE_FOLDERS" order="00" enabled="true"
defaultAll="true" defaultManager="true" defaultGuest="false"
managerEnabled="true" guestEnabled="false"/>
|
|
For actions that are valid for multiple tab types, put the entry under all the section you want it to affect.
|
2. In roleAccessResource.java, add a new resource entry for the action display name:
@RBEntry("Create Folders")
public static final String PROJECT_CREATE_FOLDERS =
"PROJECT_CREATE_FOLDERS";
◦ Recompile the bundle from a Windchill shell:
javac -d codebase -encoding UTF8
src/com/ptc/netmarkets/roleAccess/roleAccessResource*.java
3. In <Windchill>/codebase/config/actions/actions.xml, modify the create folder action by: adding the attribute uicomponent="PROJECT_CREATE_FOLDERS"
<action name=" folder_create" checkaccess="true"
uicomponent="PROJECT_CREATE_FOLDERS">
|
|
Follow best practices in backing up your XML files when customizing them.
|
4. Restart the servlet engine and the method server.
Steps 1 through 3 above can be performed in any order. Note that "PROJECT_CREATE_FOLDERS" is used for the uic name, the resource entry constant (but without the quotes), and the action uicomponent. It is necessary for all three of these items to share the same value in order to tie the customized behavior together.
Upon completion of this procedure, an administrator can now configure the visibility to the Create Folders action under the Project, Program, Product, and Library tabs, based on profiles defined at the site or organization level, and based on roles at the container level.
Parent topic
