| Agile Product Lifecycle Management Administrator Guide Release 9.3.6 E71145-01 |
|
 Previous |
 Next |
| Agile Product Lifecycle Management Administrator Guide Release 9.3.6 E71145-01 |
|
Previous |
Next |
This chapter examines the criteria used in Agile PLM workflows, and explains how to create reusable criteria.
A reusable criteria is a database query, just like an advanced search. The attributes used to create reusable criteria are similar to the attributes used to create advanced searches. They are also like filters that qualify the objects moving through a workflow process or the conditions for which the privileges masks apply.
The Criteria node is where reusable criteria are stored and maintained. From this node, you can create, delete, or modify the reusable criteria that are a fundamental building block of Agile PLM workflows and privileges. Reusable criteria are also used to define designated escalation persons and signoff transfer authority.
Reusable criteria can be assigned to multiple workflows, and to multiple statuses within a single workflow. You can define criteria that:
Specify or distinguish combinations of approvers, observers, or acknowledgers, whether they are selected users, existing or created global groups, or even personal groups.
Specify each of the company's product lines.
Correspond to Agile PLM classes.
Correspond to any other combination of attributes of Agile PLM objects: items, changes, packages, manufacturers and manufacturer parts.
Since changes to the reusable criteria for these workflows are global (that is, a refinement to a reusable criteria affects every workflow in which it appears), you can complete systemwide changes to your workflows in one step.
By specifying a list of reusable criteria for each workflow, you limit which changes can use a specific workflow. For more information about reusable criteria applied as matching criteria, see "Using Affected Items Tab Fields in Reusable Criteria."
To view the available reusable criteria:
Under Data Settings, double-click Criteria. The Criteria window appears.
Filter criteria records to narrow your search. For example, filter records by Description Contains Item to find all the reusable criteria for item objects. (See "Filtering Data in Java Client."
The filtered list of reusable criteria is displayed in the table. The Criteria table shows the name, description, and object type for each reusable criteria. Click a column header to sort the table by that column.
Use the buttons at the top of the window to perform various reusable criteria management tasks.
Table 10-1 Reusable criteria management task buttons
| Button | Description |
|---|---|
|
Delete |
Deletes the selected reusable criteria. A reusable criteria cannot be deleted if it is already in use. |
|
Import |
Imports an archive file (.AGI) to create a new criteria. See "Administrator Import." |
|
Export |
Exports reusable criteria data for the selected reusable criteria. See "Administrator Import and Export." |
|
Export All |
Exports all reusable criteria data. See "Administrator Import and Export." |
|
New Criteria |
Create a new reusable criteria. See "Creating a New Criteria." |
The reusable criteria can have any of the Agile PLM classes or subclasses as an object type. Many of the ready-to-use reusable criteria have been used to define privilege masks.
To view specific reusable criteria:
Under Data Settings, double-click Criteria. The Criteria window appears.
Filter criteria records to narrow your search. For example, filter records by Description Contains Item to find all the reusable criteria for item objects. (See "Filtering Data in Java Client").
In the Criteria window, click the name of the reusable criteria you want.
The tabbed window for that reusable criteria appears.
The General Information tab of the Criteria setup window has buttons you can use to perform the available actions described in the following table:
Table 10-2 Criteria Setup General Information tab buttons
| Action | Description |
|---|---|
|
Delete |
Deletes the reusable criteria if it is not in use. |
|
Export |
Exports the reusable criteria information. See "Administrator Import and Export." |
|
Save As |
Permits you to copy the reusable criteria and give the copy a new name.
|
When you double-click an existing reusable criteria, its properties are displayed in a tabbed window in the right pane. The General Information tab displays the name and description of the criteria, and object type that criteria applies to. You can use the Edit button to edit the name and description.
The Criteria tab lists the type (class or subclass) that the criteria is associated with and the criteria parameters. These are the conditions that define how each reusable criteria works.
|
Note: You can edit a reusable criteria that's already being used, but its Name, Description, and Object Type fields are read-only. |
The Where Used tab tells where reusable criteria are used in criteria-specific properties, matching criteria, privilege masks, escalations, and transfers. The History tab lists the actions that have been performed in relation to this reusable criteria.
You create reusable criteria according to the needs of your workflow or privilege mask. Because reusable criteria can be widely used in Agile PLM, their purpose and function need to be clear from the start.
It is recommended that you devise a system or convention for naming reusable criteria.
|
Note: Although you can change the name of reusable criteria at any time, doing so too often may confuse users, who do not see a name change until they have logged out and back into the Agile PLM client. |
A possible naming scheme could be: object type, attribute field, value, for example, MCO Engineer User.
For example, a criteria name of "MCO_Acme_July2000" is a lot easier for your users to decipher than "MCO6."
|
Note: Reusable criteria created by the Agile PLM administrator appear in the Transfer Authority dialog as Global.Criteria name. Personal reusable criteria created by other users appear in the Transfer Authority dialog box as User.Criteria name. |
To create a new reusable criteria:
Under Data Settings, Agile PLM Criteria. The Criteria window appears.
Click the New button. The Create Criteria dialog box appears.
Fill in the Name, API Name and Description fields, and select the object type that your reusable criteria will apply to. This list comprises all the Agile PLM classes and subclasses.
|
Note: The reusable criteria name must be unique. If you specify a reusable criteria name that is already used, you get a duplicate name error message. |
If you want the criteria to be case-sensitive, select the Case Sensitive check box. Case-sensitive searches improve system performance and can simplify how you define reusable criteria:
If you enter text in the Value field, the criteria will look for text that is an exact match.
If you define a numerical value, checking Case Sensitive enables the Agile PLM system to make use of internal database settings to find objects more quickly.
Click Add and select the Agile PLM attribute you want from the Attribute drop-down list. The values that are available change according to the Agile PLM class or subclass you selected in the previous step. Click OK in the small dialog box.
Click the Match if field and specify the search operator.
Click the Value field, and select a value for the field you selected from the Attribute list. Click OK in the small dialog box.
If you are going to add additional conditions, click the Add button again, and then in the And/Or field, select And or Or.
You can click the Insert button to add a condition above the currently highlighted row.
Repeat step 5 through step 9 until your reusable criteria is complete.
When the criteria is complete, Click OK.
|
Note: Changing the criteria in the Object Type field resets the entire reusable criteria. A reusable criteria covers one entire Agile PLM class or subclass. You need to create a separate global criteria to cover a different class or subclass. |
Click the ( ) button to place parentheses around the specified condition or conditions, which changes the order in which the search conditions are evaluated. The ( ) button functions like a formula within parentheses in an algebraic equation, following the standard algebraic order of operations. The grouped criteria within parentheses are resolved before any others.
A criteria already in use can be edited. When the user tries to save the changes made, a warning message appears reminding the user that there are objects currently using the criteria, as previously defined. The user can then confirm the changes to the criteria definition or cancel the changes.
You can also use a criteria as a template by removing the reusable criteria from its assigned objects, modifying it, and then reassigning it. The Where Used tab lists all the objects where the reusable criteria is in use.
To modify an existing reusable criteria:
Under Data Settings, double-click Criteria. The Criteria window appears.
Filter criteria records to narrow your search. For example, filter records by Description Contains Item to find all the reusable criteria for item objects. (See Filtering Data"Filtering Data in Java Client.")
In the Criteria window, double-click the name of the reusable criteria object you want.
The criteria definition page with the General Information, Criteria, Where Used and History tabs appears. Click the Criteria tab.
Next, click the button to the right of the criteria definition.
In the Edit Criteria window make your desired changes and click OK.
A warning message appears if the criteria is already in use. Click Yes to continue saving your changes.
You cannot delete a reusable criteria once it has been used to create a Transfer Authority privilege, even when you delete that transfer authority. You might rename the criteria you want to delete so it is, for instance, dropped to the bottom of the list of reusable criteria.
There are many similarities between reusable criteria and other searches in the Agile PLM system, but there are a few important differences.
To select a specific routable object in Agile PLM clients, an affected items field condition must be true for all the objects on the Affected Items tab of that routable object. For example, if you specify Affected Items.Old Lifecycle Phase Equals Preliminary, then all the objects on the Affected Items tab must have the Old Lifecycle field equal to Preliminary. If you select Contains as the search operator, then every object on the Affected Items tab must contain the specified value in the specified field.
When you create a reusable criteria in Java Client, you can include criteria conditions against item fields (such as Part Category), provided the item fields are displayed on the Affected Items tab of the routable object.
|
Note: Criteria that specify Affected Items attributes cannot be used to create privilege masks. If a criteria does not appear in a privilege mask's drop-down list, it cannot be used to define the privilege mask. See also the "Configuring Product Collaboration in Agile Administrator" chapter of Agile PLM Product Collaboration User Guide. |
In the Create Criteria dialog box, the Attributes list contains Affected Items tab fields, including those from the Items themselves. This enables you to create reusable criteria that return changes according to fields of the Items that appear on the Affected Items tab. For this kind of query to work, the Affected Items tab field must be visible.
For example, to find changes with Items on their Affected Items tab that have a Part Category field equal to Engineering, do the following:
Under Data Settings, double-click Classes. The Classes window appears.
Click the class you want (for example, Change Orders).
In the Class setup window, click the User Interface Tabs tab.
Double-click Affected Items. The Class Tabs setup window appears.
Click the Attributes tab.
Find Item Category in the Name column. double-click the row to display the Attributes setup window.
In the Visible drop-down list, select Yes. The Visible property is now set to Yes.
It is important to understand how the system interprets the naming of affected items when you create reusable criteria, as shown in the following table:
Table 10-3 Naming of Affected Items in Reusable Criteria
| Name (general) | Applies to... | Name (example) | Applies to... |
|---|---|---|---|
|
Affected Items.Item fieldname |
Parts and documents |
Affected Items.Items.P2 Text20 |
Text20 field for both parts and documents |
|
Affected Items.Part fieldname |
Parts only |
Affected Items.Part.P2 List03 |
List03 field for part |
Most list and multilist fields for Documents class objects cannot be used to create reusable criteria. For instance, the list fields on Page Two and Page Three tabs are not available. The two available Documentation list fields are Documentation.Product Line and Documentation.Size.
Default change analysts (or default component engineers) may want to monitor changes assigned to them to ensure that the list of approvers, observers, and acknowledgers is complete. When workflows assign approvers, acknowledgers, and observers according to the attributes of the affected items of a routable object, you may want to add approvers that were not automatically assigned by the workflow.
For example, at Acme Inc., each product line has several projects in development simultaneously. Acme uses a field on Page Two (in Agile Java Client) to identify which project or projects each item (part or document) belongs to. The Libra Product Line workflow looks at the project assigned to the affected items on an ECO to determine which default approvers, observers, and acknowledgers to assign.
Mary Green creates ECO 333 in Agile Java Client. She adds six Orion project objects to the Affected Items tab: three parts and three documents. Mary finishes preparing ECO 333 and switches it to the next status, where the change is submitted to Bob Smith, the default change analyst.
To select approvers for the Orion project, the Libra Product Line workflow examines each item on the Affected Items table to determine if the Page Two field contains Orion. If any the items on the Affected Items table belong to the Orion project, then the list of Orion approvers, as defined in the workflow, are automatically added to the Workflow tab when ECO 333 is submitted to Bob.
However, when some of the objects on the Affected Items table are documents, Acme requires that Orion team members in the Publications department must also sign off the change. Since not all ECOs include documents to sign off, the Libra Product Line workflow does not automatically add approvers from the Publications department to every ECO.
Bob, the change analyst, examines ECO 333 and notices that some of the affected items are documents. Bob clicks the Add Reviewers button on the Workflow tab of ECO 333 and adds all the members of the Orion Publications group as approvers. Bob can add approvers to any future Review or Released status type; the ECO does not need to be in the Review or Released status type for approvers, acknowledgers, or observers to be added.
$CURRENTREV and $LATESTREV are two powerful system variables available to the administrator to construct criteria that can target specific revisions of items (parts and documents) and specific workflow statuses (for those workflows that apply to rev-based changes, that is, Change Orders, Sites Change Orders, and Manufacturer Orders).
Be aware that this functionality is quite granular and will be best understood when you have become familiar with item revisions (in Production Collaboration) and workflows. It may be helpful to request assistance from your Oracle Consulting - Agile Practice representative.
These variables are also used to construct some criteria in Privilege Masks, which is another area of robust capability and granularity. Variables were introduced in Getting Started in Administrator, see "Default Value Variables"; $CURRENTREV in conjunction with the Modify privilege is detailed in "Controlling the Ability to Modify Items at Introductory Revision with $CURRENTREV".
Title Block.Rev is currently not available for use in criteria conditions. Instead, use $CURRENTREV criteria conditions to identify which revision the user has selected.
The $CURRENTREV variable is used to construct criteria based on the workflow status of the change (Change Order or Manufacturing Change Order) that corresponds to a selected item revision.
The following rules govern the usage of the $CURRENTREV variable:
$CURRENTREV may only be used in defining criteria against objects belonging to the Items base class (including Parts and Documents classes and their subclasses).
$CURRENTREV is available as a value in the Attribute list. $CURRENTREV itself does not evaluate to a value: the entire condition itself is evaluated as an expression.
The Match If operator can be set to Equal To and Not Equal To.
Value can be set to the following values.
The list of values is comprised of $STATUSTYPE variables for all predefined Change Status Types, and also all possible Workflow.StatusName values for all configured Workflows created for the Changes object type.
|
Note: The only Change types that are pertinent to this feature are the ones that appear in the Item's Rev drop-down list, that is, those belonging to Change Orders (ECOs), Manufacturer Change Orders (MCOs), and Site Change Orders (SCOs) classes. However, the other Change classes (Change Requests, Deviations, Stop Ships, and PCOs) do appear in this list. For expressions pertaining to $CURRENTREV, only statuses pertaining to workflows developed for ECOs, MCOs, and SCOs should be used. |
The condition $CURRENTREV Equal To $STATUSTYPE.PENDING evaluates to True if the selected item revision corresponds to a Change whose current status type is Pending. Similar statements can be constructed for other status types as well. The supported status type variables include:
$UNASSIGNED
$STATUSTYPE.PENDING
$STATUSTYPE.SUBMIT
$STATUSTYPE.REVIEW
$STATUSTYPE.RELEASED
$STATUSTYPE.COMPLETE
$STATUSTYPE.HOLD
Note that $STATUSTYPE.CANCEL is not available, since revisions pertaining to Canceled changes do not appear in the Rev drop-down list for items, and therefore may not be selected. In any case, the expression $CURRENTREV Equal To $STATUSTYPE.CANCEL would always evaluate to False.
The condition $CURRENTREV Equal To Default Change Orders.Pending evaluates to True if the selected item revision corresponds to a change that is assigned the Default Change Orders workflow, and whose current status is Pending. Similar statements can be constructed for other workflows and statuses as well. The general format is:
<WorkflowName>.<StatusName>
Note that <WorkflowName>.CANCEL is not available.
While the workflow status values above cover all possible statuses for a pending or released revision, special criteria values are provided for the Introductory revision because there are no changes associated with that revision.
Based on the possible use cases, one of the following conditions would hold true when an Introductory revision of an item is selected (the term Pending change below implies a change in its pre-Released state, for example, Submitted, Review):
$INTRODUCTORY_NOCHANGE – There are no Pending or Released changes against the item (the Changes tab is empty). This condition also covers the case where any past Pending changes against the item have been soft or hard deleted from the Agile system.
$INTRODUCTORY_PENDINGCHANGE – The item has never been released, but there are Pending changes against the item. This condition also covers the case where the item has been released in the past, but the released changes have all been unreleased
$INTRODUCTORY_RELEASEDCHANGE – The item has one or more released changes against it. It may also have one or more Pending changes against it.
An expression involving any of these three values will always evaluate to False if the selected revision is not the Introductory revision.
To support the use case where users are allowed to read, make changes to or get file attachments from only the latest released revision of an item (this is important in regulated industries (for example, medical devices) where it is important that users refer to only the latest design or spec files), another variable called $LATEST is introduced to the set of valid values for $CURRENTREV expressions. The expression $CURRENTREV Equal To $LATEST evaluates to True if the selected revision is the Latest Released revision for the item. This expression also evaluates to True if the selected revision is Introductory and the item does not have any Released ECOs, MCOs or SCOs against it.
The expression $CURRENTREV Equal To $LATEST has the exact same functionality as the obsolete expression Title Block.Rev Equal To $LATEST.
The behavior of item Description on the Latest Released revision deserves special mention here. When a user has the privilege to modify the Latest Released revision only (Title Block.Rev = $LATEST) and not Pending revisions, and he modifies the description of the item, he is presented with a message asking if he'd like to update the description of all the pending revisions to this updated description. If the user chooses to do so, all the pending revision descriptions are also updated irrespective of whether or not the user has privilege to update descriptions on pending revisions.
The $LATESTREV variable is another Administrator attribute used to construct criteria based on the workflow status of the Change Order (ECO/MCO/SCO) corresponding to the latest released revision of an item.
The following rules govern the usage of the $LATESTREV variable:
$LATESTREV may only be used in defining criteria against objects belonging to the Items base class, which includes Parts and Documents classes and their subclasses.
$LATESTREV is available as a value in the Attribute list. $LATESTREV itself does not evaluate to a value. The whole condition itself is evaluated as a boolean expression.
Unlike $CURRENTREV, you must specify only the Match If field to construct a valid expression using $LATESTREV. The only operators available for Match If are Is Released and Is Introductory.
The condition $LATESTREV Is Released evaluates to True if the selected item has been released on at least one Change of type ECO or MCO. Note that SCO is not included because an item has to be released on an ECO or MCO before it can be released on an SCO.
The condition $LATESTREV Is Introductory evaluates to True if the selected item does not have any released ECO or MCO against it.
To create a relationship and a relationship rule between any two Agile objects requires that the user has Modify privileges for both objects applied to <object>.Relationships.Name attribute (to create a relationship) and <object>.Relationships.Rule (to create a relationship rule). See "Some 'Modify' Basics and Rules."
Modify Item privilege masks that use a $CURRENTREV criteria condition to limit item modification also limit which items can be selected for item-to-item relationships. For example, if a user has a Modify privilege that limits his Modify Item privilege mask with the criteria condition $CURRENTREV Equal To $STATUSTYPE.PENDING, that user can modify only items with a change in the Pending status. The items that can be selected for item-to-item relationships are also limited to items with a change in the Pending status.
To avoid this limitation to item-to-item relationships when using $CURRENTREV criteria conditions in Modify Item privilege masks, use the following criteria:
$CURRENTREV Equal to $LATEST
To create a Modify privilege mask with only one Applied To attribute, Item.Relationship.Name, use the following criteria:
Modify Items $CURRENTREV Equal to $LATEST Applied To Item.Relationships.Name
To ensure that users can create item-to-item relationships between any two items, include this Modify privilege mask in any role that includes Modify Item privilege masks.
|
Note: Relationship rules are not revision-specific. See also Chapter 43, "Administering Revision-Specific Relationships." |
For file folder objects privilege checking is based on the latest checked in version of the file folder object. Privilege checking is not performed on checked out versions of file folders.
For example, if you create a Discover privilege mask using a criteria that requires the file folder lifecycle phase attribute to equal Pilot, then a checked out version of a file folder with the Pilot lifecycle phase will not be discovered. However, once the user checks in the file folder, then the checked in file folder will be discovered because the lifecycle phase of Pilot now meets the criteria.
