3 Managing Metadata

This chapter discusses the following topics about managing repository metadata with schemas, rules, and profiles:

3.1 Using Schemas to Customize Metadata

This section covers these topics:

3.1.1 About DCLs and Metadata Schemas

The Information Fields tab of the Configuration Manager enables you to create custom metadata fields with option lists. Additionally, you can structure an information field to make its associated option list dependent on another information field's option list. This organization is called a dependent choice list (DCL).

For example, assume there is an option list for a Country information field and another option list for a State information field. The available choices in the State option list would be dependent on which country was selected from the Country option list.

The metadata schema mapping feature is similar to the dependent choice list function in that a hierarchical structure can be created for information field option lists. However, the metadata schema mapping is more versatile. Option list views can be easily adjusted to accommodate localization requirements.

The Content Server metadata schema mapping feature involves the structure that is set up and used to manage information lists and corresponding option lists. A metadata schema defines the option lists (contained in database tables), the available choices (values in the table columns), and dependencies (relationships) between the choices and option lists.

Schemas can be complex to set up. If you have any questions prior to setting up a schema, contact Consulting Services to review your plans.

Note:

Because Internet Explorer 5.0 does not support DHTML, any DCLs created using the Content Server schema mapping feature do not display the option list values. This is not an issue with Internet Explorer 6.0.

When using schemas with Content Publisher, wrapping a query page in a table causes an error in Internet Explorer. This is caused by the interaction of schema with the page.

This section covers the following topics:

3.1.1.1 Schema Hierarchical Structure

A schema is a collection of related schema objects. The term schema also refers to a graphical depiction of the database hierarchy that is created to support the Content Server metadata schema mapping feature. The schema hierarchical structure consists of tables and their respective columns (or fields), views of the data, and the relationships between them.

The Country and State example can be continued to more fully describe a schema hierarchy. Additional information fields (City, Region, and Area Code) are included to illustrate a three-tiered dependency structure.

In Figure 3-1, the sample basic schema hierarchy, one independent field has two dependent fields. Each dependent field also has a dependent field. These dependencies are also referred to as Parent/Child relationships.

Figure 3-1 Basic Schema Hierarchy Example

Surrounding text describes Figure 3-1 .

This three-level schema hierarchy produces five distinct metadata fields: Country, State, City, Region, and Area Code. Each field presents a specific option list to the user.

The contents of the option lists are contingent on whether the information field is dependent or not. Thus, the following option lists result from the sample basic Country/State/Zip schema hierarchy:

  • The Country option list is independent and the choices remain constant.

  • The choices available in the State option list are variable and depend on which country the user selects from the Country option list.

  • The choices available in the City option list are variable and depend on which state the user selects from the State option list.

  • The choices available in the Region option list are variable and depend on which country the user selects from the Country option list.

  • The choices available in the Area Code option list are variable and depend on which region the user selects from the Region option list

3.1.1.2 Schema Elements

Schemas are comprised of:

3.1.1.2.1 Tables

Schema tables are database tables that store the choices displayed in information field (metadata) option lists.

Tables and their columns are created using the Tables tab (see "Configuration Manager: Tables Tab"). Multiple columns can be created in each table but at least two are essential for producing dependent choice lists:

  • The common column name used to create the dependency between one option list and a second option list that is dependent on the choice made from the first (for example, Country and State, respectively).

  • The column that stores the choices for metadata option lists.

Figure 3-2 Schema Tables Example

Surrounding text describes Figure 3-2 .

Using the geographical example (Country, State, City, Region, Area Code) in the three-tiered schema hierarchy, a table must be created for each branch in the schema tree structure. Additionally, the dependent tables (child tables) must contain a column that corresponds to an identical column in the table to which it is subordinate (the parent table). These corresponding columns are used to create the dependencies between the two tables and are ultimately used to generate the dependent choice lists.

For example, the tables in Figure 3-3 illustrate how the Country and State table columns might be populated. The data in each name column provides the choices available on the option lists. The relationship that is created between the corresponding columns in the Country and State tables (countryID) determines what choices are displayed in the State metadata option list.

Figure 3-3 Populated Schema Tables

Surrounding text describes Figure 3-3 .
3.1.1.2.2 Views

A view is a tailored presentation of the corresponding table. Views do not contain data, but they derive data from their tables. Views are used to simplify a database for use and to present data in a different perspective.

A view consists of a list of properties and associated display rules. Each table in the schema must have an associated view. Views provide information about these items:

  • Specific columns in the table included in the schema. The selected columns are used to establish the dependencies between tables and also to generate the dependent choice lists.

  • Internal and external column names.

  • User interface display characteristics.

  • Editing and sort order criteria.

3.1.1.2.3 Relationships

Relationships define the dependencies between tables and are essential in generating the appropriate dependent choice lists. Each defined relationship establishes the correspondence between parent and child tables. This correspondence is created by specifying the column in the child table that is dependent on the column in the parent table. Thus, the choices displayed using column data from the child table are contingent on the choice made from the corresponding column data from the parent table.

Figure 3-4 Table and Column Relationships

Surrounding text describes Figure 3-4 .

For example, in Figure 3-4, the CountryView (Country table) and the StateView (State table) use the countryID column to create a relationship that generates a parent country list and a child state list. This means that the choices available in the State metadata option list are dependent on the choice made in the Country metadata option list.

3.1.1.3 Sample Schema-Based Option Lists

After the schema tables, views, and relationships are created and properly established, the option lists display the appropriate choices. For example, in Figure 3-5, the Country option list now displays two choices: United States and Canada.

Figure 3-5 Option List Example

Surrounding text describes Figure 3-5 .

Because the State metadata field is contingent on the Country field, the State option list contains items based on the choice made in the Country option list. In this case, if the United States choice is selected, the State option list displays Minnesota and Wisconsin as choices. If Canada had been selected, then the State option list would display Ontario and Quebec.

Figure 3-6 Dependent Option List Example

Surrounding text describes Figure 3-6 .

3.1.1.4 Directory Structure for Schema

Three subdirectories are associated with the Schema function:

  • schema

  • schema.work

  • schema.old

These are located in the /weblayout/resources directory.

The schema.work directory is usually not listed because it is a temporary directory. When the schema creation process completes, the directory is renamed. If this directory exists it indicates one of the following:

  • A large schema rebuild is in progress

  • The schema is created, but there is a problem with the schema structure.

    Caution:

    If you are working inside the directory structure to review the Schema files and directories, be sure to close all open applications that are accessing these files. The directories are renamed on completion of processing. However, if external applications, such as text editors, are using these files the schema.work directory cannot be renamed.

3.1.2 Creating Schemas

The Tables, Views, and Relations tabs in the Configuration Manager are used to create the schema structure.

  • The Table tab is used to select or create the database tables.

  • The Views tab is used to manipulate the views used in the schema.

  • The Relations tab is used to manipulate the dependencies.

The Information Fields tab is used to create the metadata fields that are used on Content Server pages. The metadata fields must be correlated to the tables and views to properly display the option lists.

New or modified schemas are automatically updated during each scheduled publishing cycle. Because the default interval between each publishing cycle is set to four hours, you will not see immediate results for new or modified schemas. You can, however, adjust the interval between each publishing cycle by changing the default value of a configuration variable. For more information, see "Modifying the Publishing Cycle Interval".

This section covers the following topics:

3.1.2.1 Building a Basic Schema

This section provides an overview of a simple sequence using the applicable Configuration Manager tabs to create a schema structure. See "Schema Interface Screens" for representations of the screens used to create a schema.

This section covers the following topics:

3.1.2.1.1 Selecting Tables for the Schema

To select tables for the schema:

  1. Select the "Configuration Manager: Tables Tab").

  2. To add tables to the schema, select Add Tables and choose the tables to add to the schema from the Select Table Screen. If you are creating a new table, select Create Table.

    Important:

    While you can use core Content Server system tables such as Revisions, Alias, Documents, and Users you cannot edit those tables (remove columns, alter column length, etc.)
  3. After selecting the tables to use, the Create/Edit Table 'name' Screen is displayed with Table Column names filled in.

  4. Select the column that will be used as a primary key to establish a dependency and select Edit. The Add/Edit Column Screen is displayed.

  5. Check the box labeled Primary Key and click OK. Select Add Recommended to add recommended columns to the table.

Repeat these steps for all tables that will be used together in the schema. When finished, click OK.

3.1.2.1.2 Creating the Schema View

To create the schema view:

  1. Select the Configuration Manager: Views Tab. The names of configured views are displayed.

  2. To create a new view, click Add to open the Add View Screen: Select Table page.

  3. Select the table to use in the view, and click Next. The Add View Screen: Select Columns page is displayed.

  4. Choose the columns to include in the view, and click Finish. The Add/Edit View Screens is displayed.

  5. Select a name for the view, and add information for the description. Choose the internal column (name in the database) to use in the view, and choose the visible column that is displayed to end users. You can also set a display expression, which determines how the name in the option list will be displayed. When done, click OK.

  6. Repeat these steps for all tables to be included in the view.

3.1.2.1.3 Creating the Schema Relationships

To create the schema relationships:

  1. After the tables and associated views are completed, select the Configuration Manager: Relations Tab to establish the dependencies between tables and columns. A list of the currently existing schema relationships is displayed.

  2. Click Add to set up a new schema relation. The Add/Edit Relationship Screen is displayed.

  3. Enter the name of the relationship (for example, Country_State to indicate the relationship between the Country and the State tables). In the Parent Info box, select the table where the parent information resides (for example, the Country table) and the column that will be used to establish the dependencies (for example, the Country ID). Do the same for the Child Info field (for example, selecting State as the table name and countryID as the relationship).

  4. Click OK when done. The new relationship is now displayed on the Relations list.

3.1.2.1.4 Adding Metadata Fields

The final phase in schema creation is to set up the metadata fields to use the columns and to configure them to use the Views and Relations created previously. See "Adding a Metadata Field" and "Defining an Option List" for an overview of this procedure.

3.1.2.1.5 Enabling the Schema

After the configuration of the schema, the views, and the relationships is completed, you must update your database design (a selection key on the Configuration Manager screen) and you should click Options, Publish Schema from the Configuration Manager menu.

Republishing (updating) of schema takes place automatically based on these things:

  • Existence of the data/schema/publishlock/publish.dat file.

  • The internal schedule of automatic publishing times. See "Modifying the Publishing Cycle Interval" for details.

  • How long it took to publish schema last time.

Do not select Options, Publish Schema unless you need to see the new Content Type quickly and do not mind the load on the system that may occur when large option lists are republished.

3.1.2.2 Modifying the Publishing Cycle Interval

New or modified schemas are automatically updated during the automatic schema publishing cycle. However, by default, the interval between publishing cycles is set to four hours. This means that new schemas or changes to existing schemas will not be seen in the corresponding menu lists until the completion of the next publishing cycle. However, you can adjust the publishing cycle interval by changing the value of the SchemaPublishInterval configuration variable.

To change the interval of schema publishing cycles:

  1. In a text editor, open the IntradocDir/config/config.cfg file.

  2. Add the following configuration variable and value:

    SchemaPublishInterval=300
    

    The value is specified in seconds. Therefore, in this configuration example, the option lists will be republished every 300 seconds (i.e., 5 minutes).

    Note:

    Depending on the number of option lists in addition to the size and complexity of each list, automatically republishing (updating) your schemas frequently may have a significant impact on your system's performance.
  3. Save and close the config.cfg file.

  4. Restart Content Server to apply the changes.

    Note:

    The queries for schema publishing are cached up to five minutes. Therefore, publishing more frequently will not retrieve new values until the current cache expires.

    If a new value is added to a metadata field, that value will not be displayed on the content item's Content Information page until the next publishing cycle is complete.

    If one content item is checked with a unique value in a dynamic option list and a second item is checked in with the same value but using a different case, the value is treated as one value in the option list. The case used is dependent on the database sorting scheme.

    For more information about creating dynamic option lists, see "Schema Example: Dynamic Option Lists".

3.1.3 Schema Example: Dynamic Option Lists

Creating a dynamic option list enables users to add values to metadata option lists. For example, if a value already exists in an option list, users can select the value from the list. However, if it's a new value, users can enter the value into a text field and it becomes available as an option following the next publishing cycle. For more information about automatic publishing cycles and their intervals, see "Modifying the Publishing Cycle Interval".

To create a dynamic option list, first create a view into the table in the database. The option list values are pulled directly from the metadata columns where they are stored. As content items are checked in, revised, and removed, the option list values change or are updated accordingly.

The following is an example of creating a dynamic option list:

  1. Click the Admin Applets link in the Administration Tray.

    The Administration page is displayed.

  2. Click the Configuration Manager icon.

    The Configuration Manager: Information Field Tab is displayed.

  3. Click Add on the Information Fields tab.

    The Add Metadata Field Name Screen is displayed.

  4. Enter the name of the metadata field that has the dynamic option list. For example, TestMetadata.

  5. Click OK.

    The Add/Edit Metadata Field Screen for TestMetadata is displayed.

  6. Complete the fields as desired but do not select the Enable Option List check box.

  7. Click OK.

    The screen is closed and the metadata field is added to the Field Info list on the Configuration Manager: Information Field Tab.

  8. Click Update Database Design.

    The Update Database Design Screen is displayed and informs you that the TestMetadata will be added.

  9. Click OK.

  10. Open the Configuration Manager: Views Tab and click Add.

    The Add View Screen: Select Table screen is displayed.

  11. Click Add Table.

    The Select Table Screen is displayed.

  12. Select the DocMeta table.

  13. Click OK.

    The Select Table screen is closed and the DocMeta table is added to the Tables list on the Add View Screen: Select Table screen.

  14. Click Next.

    The Add View Screen: Select Columns screen with column names is displayed.

  15. Select the column you want to use to create the option list for TestMetadata.

  16. Click Finish.

    The Add/Edit View Screens page is displayed.

  17. Enter a view name. For example, TestMetadata_view.

  18. Click OK.

  19. Open the Information Fields tab on the Configuration Manager: Information Field Tab and select TestMetadata.

  20. Click Edit.

    The Add/Edit Metadata Field Screen for TestMetadata is displayed.

  21. Select the Enable Option List check box.

  22. Click Configure.

    The Add/Edit Custom Info Field: Configure Option List for TestMetadata is displayed.

  23. Select Edit and Select List from the Option List Type option list.

  24. Select the Use View radio button and select a view from the option list. For example, TestMetadata_view.

  25. Click OK.

    The Add/Edit Custom Info Field: Configure Option List is closed.

  26. Click OK.

    The Add/Edit Metadata Field Screen is closed.

  27. Select Publish schema from the Options menu on the Configuration Manager: Information Field Tab.

You can test this option list by checking in a document and entering a value into the new dynamic metadata field. Initially, the option list is empty because no documents have been checked in that contain data in the TestMetadata field. However, as documents are checked in with values entered in TestMetadata, the option list will include them.

3.1.4 Schema Example: Recursive Table for Multiple Trees

Creating a recursive table enables you to hold the data for multiple schema trees.

  1. Click the Admin Applets link in the Administration Tray.

    The Administration page is displayed.

  2. Click the Configuration Manager icon.

    The Configuration Manager Application Page is displayed.

  3. Create a database table with two columns (id,parent):

    1. Open the Tables tab and click Create table.

      The Create/Edit Table 'name' Screen is displayed.

    2. Enter the table name. For example, TreeTest.

    3. In the Columns pane, click Add.

      The Add/Edit Column Screen is displayed.

    4. Enter the first column name (id) and its length. Click OK.

    5. Enter the second column name (parent) and its length. Click OK.

    6. Click OK to create the table.

  4. Create a view on the table that includes both columns:

    1. Open the Views tab and click Add.

      The Add View Screen: Select Table is displayed.

    2. In the Tables pane, select TreeTest and click Next.

    3. In the Columns pane, select the id and parent check boxes and click Finish.

      The Add/Edit View Screens is displayed.

    4. Enter the view name. For example, TreeTestView.

      Optional: add display, options, and security configurations as applicable. For more detailed information, refer to "Add/Edit View Screens".

    5. Click OK to create the view.

  5. Create a relationship on the view:

    1. Open The Relations tab and click Add.

      The Add/Edit Relationship Screen is displayed.

    2. Enter the relationship name. For example, TreeTestRecursive.

    3. From the Parent Info table list, select TreeTest and in the corresponding column list, select id.

    4. From the Child Info table list, select TreeTest and in the corresponding column list, select parent.

    5. Click OK to create the relationship.

  6. Open the Information Fields tab and click Add.

    The Add Metadata Field Name Screen is displayed.

  7. Enter the custom metadata field's name and click OK.

    The Add/Edit Metadata Field Screen is displayed.

  8. Select the Enable Option List check box and click Configure.

    The Add/Edit Custom Info Field: Configure Option List screen is displayed.

  9. Select the Use Tree radio button and click Edit Definition.

    The Edit Tree Definition Screen is displayed.

  10. In the Building level pane: Select view for level1 list, select TreeTestView.

    TreeTestView is entered as Level 1 in the Tree Definition pane.

  11. In the Building level pane: Select relationship between the 1st and 2nd level list, select TreeTestRecursive.

    TreeTestRecursive is added under TreeTestView in the Tree Definition pane.

  12. In the Building level pane: Select view for level 2 list, select TreeTestView (recursive to level 1).

    TreeTestView (recursive to level 1) is entered as Level 2 in the Tree Definition pane and the Select root button is added.

  13. Click the Select root button.

    The Select Tree Root dialog is displayed.

3.2 Using Profiles to Customize Content Screens

This chapter covers these topics:

3.2.1 About Content Profiles

Administrators can use Content Profiles to configure Check In, Update, Content Information, and Search pages, so end users see only directly relevant metadata fields, thereby rendering basic pages simpler to use.

Content profiles do not create or modify any content server tables. They are simply used as a type of filter for what information will be displayed. All information for the Content Profile is stored on the file system in the IntradocDir/data/profiles/document/ directory.

This section covers the following topics:

3.2.1.1 Content Profile Elements

A profile is composed of rules and a trigger value, which are set up on the Profiles and Rules tabs of the Configuration Manager screen. Administrators can create multiple content profiles and all are available to the end user. For each profile, the end user has a distinct Check In page and Search page available. Although all profiles are visible to all users, each user can configure their user interface to hide or display links to specified profiles. See "Profile Links".

Note:

Documents cannot be associated with more than one profile in the system.

Content profiles consist of:

3.2.1.1.1 Rules

A rule consists of a set of metadata fields that determine whether fields are editable, required, hidden, excluded, or read-only based on their criteria when specific conditions are met. You can change a rule's behavior based on an input, or activation condition. A rule can be evaluated for every profile (global), or it can be evaluated for specific profiles. For ease of use, you can use rules to group metadata fields under an optional header.

For example, a profile's rules can determine the user type and, depending on the document type being checked in, ensure that only specific metadata fields are displayed. All other fields can be hidden.

Note:

Rules must be established before a profile is created. See "Profile Rules" for details.
3.2.1.1.2 Triggers

A trigger field is a metadata field that is defined on the Configuration Manager: Profiles Tab. If a document matches a trigger value for a profile, then that profile is evaluated for the document. There can be an unlimited number of profiles, but only one trigger value per profile.

Note:

Although you create rules before you create triggers and profiles, it is necessary to know what your trigger will be prior to creating rules.

3.2.1.2 Profile Links

When a profile is enabled on the Edit Content Profile Links page, the profile is available from the Search and New Check In menus on the toolbar. If no profiles are enabled for display, the Search and New Check In menus become direct links to the Advanced Search page and standard Content Check In Form, respectively.

After a profile has been created, it appears in the Search and New Check In menus on the toolbar when you refresh your browser session. By default, all profiles are listed as options under both menus. However, not every user will be authorized to use all of the listed profiles. On the Edit Content Profile Links page, users can decide which profiles to display by selecting or clearing applicable check boxes.

For example, a marketing employee may not have the necessary privileges to use an accounting profile. In this case, the user can clear the check boxes for the accounting profile and it does not display under Search and New Check In menus. For more information about the user interface in general and the content profile links in particular, see the Oracle Fusion Middleware User's Guide for Content Server.

3.2.2 Content Profile Rules

This section covers these topics:

3.2.2.1 Profile Rules

A profile consists of one or more rules and a trigger value (see "Content Profile Elements"). The rules determine how metadata fields are displayed on the Check In, Update, Content Information, and Search pages and if a rule will be used (depending on how it is evaluated). Each rule consists of the following:

  • A set of metadata fields. See "Metadata Fields and Attributes in Rules".

  • An optional activation condition. See "Activation Conditions in Rules".

  • An option that indicates if it is a global rule and has a specified priority.

  • An option that indicates if the metadata fields in the rule can be relocated by grouping and if an optional header is used.

    Note:

    Although you create rules before you create triggers and profiles, it is necessary to know what your trigger will be prior to creating rules.

3.2.2.2 Global Rules

Global rules are always 'on' (always evaluated). A global rule automatically affects the metadata fields displayed on the Check In, Update, Content Information, and Search pages even if it is not included in a profile or even if no profiles have been created. It is not necessary for a profile to exist in the system for any defined global rules to take effect and be applied to events, actions, or workflow states. However, you cannot preview the effects of a global rule unless it is associated with a profile.

Global rules are evaluated first and can be superseded by specific profile rules. You can set the priority for the global rule, though, and increase its precedence. It may then have a higher priority than specific rules and produce different profile results. You can view those results by previewing the profile and seeing the consequence of rule selection. See "Preview Profile Screen" for more details about previewing profiles and viewing how rules affect the profile.

A global rule obeys the following guidelines:

  • It is always on, is independent of a profile, and is always evaluated.

  • For documents and searches with profiles, the global rule is evaluated first. The specific profile rules are evaluated after the global rule. This means that global rules have a lower priority with respect to profile rules.

  • Global rules have a priority number, see "Add/Edit Rule Screens". The priority determines the order in which the rule is evaluated. Lower priority rules are executed earlier and rules with higher priority can override changes made by rules with lower priority.

3.2.2.3 Metadata Fields and Attributes in Rules

Each metadata field in a rule has the following attributes:

3.2.2.4 Activation Conditions in Rules

An activation condition allows you to change the profile behavior based on various different inputs. For example, a rule may not be active for the search page. For a contributor, certain fields may be hidden or overridden on check in. Also, because profiles are activated during any check in process, distinctions are made between a browser check in and a batch load check in.

Profiles can be previewed to assess the validity of the activation conditions that may be included in the profile rules. The previewing screen allows you to check the existing profile as well as perform what-if scenarios by changing activation condition choices and evaluating the results. See "Preview Profile Screen" for details. The documentation for the Edit Activation Condition screen provides more detailed information about activation condition choices and how they are created and defined (see "Edit Activation Condition Screen Tabs").

An activation condition for a rule can be based on:

  • System event

    System event-based activation condition choices include on request events, on submit events, and on import events.

  • User action

    User action-based activation condition choices include check in new, check in selected, content information, content update, and search.

  • Workflow state

    State-based activation conditions are contingent on whether the content item is in workflow or not.

  • Document type

    Activation condition clauses can use components based on document metadata fields.

  • User type

    Activation condition clauses can use components based on user metadata fields.

    Caution:

    Be very careful when using activation conditions that include one or more combinations of condition choices. Not all combinations of activation condition choices are valid and some may be mutually exclusive. For example, if an activation condition requires the event to be an import and the action to be a document information page request, the activation will never be true and the rule will never be active.

3.2.2.5 Restricted Lists to Modify Defined Option Lists

The restricted list is an optional attribute that can be defined for a metadata field in a rule. Two methods can be used to modify the user interface list for metadata fields defined as option lists.

  • Specifying a fixed list:

    Using a restricted list allows you to specify an explicit set of values that override the actual master list for the metadata field that was defined as an option list. Only those items already in the master option list are displayed in the user interface list.

  • Using regular expression evaluation:

    You can also choose to use regular expressions to evaluate the option list. The list can include wild cards and other special characters for string pattern matching and evaluation processes. The items displayed in the user interface list are those values that satisfy the regular expression.

    Note:

    This section provides only a brief overview of using regular expression evaluation to generate modified user interface drop-downs for option list metadata fields. Regular expressions are currently supported with restricted lists. Because of the complexity of regular expressions, system administrators should be familiar with regular expressions, building patterns, and implementing regular expression methods. If not, use Oracle consulting services to assist you in defining restricted lists.

This section covers the following topics:

3.2.2.5.1 Regular Expressions

Regular expressions are ideal for text manipulation and describe the format of strings. In its simplest form, a regular expression is the text to match.

For example, the regular expression 'ABC' matches the string ABC but not the string DEF. Wild card characters, such as the asterisk (*), can be used to match more strings. For example, the regular expression 'A*B' will match the strings B, AB, AAB, AAAB, etc. The asterisk (*) is a quantifier on the preceding character.

3.2.2.5.2 Commonly Used Elements of Java Regular Expressions

The following table lists the most commonly used modifiers, metacharacters, and special characters used in building patterns for regular expression evaluation.

Modifiers:

Element Definition
g Global pattern matching.
i Case-insensitive pattern matching.
m Allows the special characters ^ and $ to match multiple times within a string.
s Allows the special character . to match newlines.
x Ignores whitespace within a pattern.

Metacharacters:

Element Definition
\s Matches whitespace (including tabs and newlines).
\S Matches anything that is not whitespace.
\b Matches only a word boundary.
\B Matches only nonword boundaries.
\d Matches digits 0 through 9.
\D Matches only nonnumeric characters.
\w Matches only letters, numbers, or underscores.
\W Matches only characters that are not letters, numbers, or underscores.
\A Matches the beginning of a string only.
\Z Matches the end of a string only.

Special Characters:

Element Definition
* Matches zero or more occurrences of the preceding character.
+ Matches one or more occurrences of the preceding character.
? Matches zero or one occurrence of any character.
. Matches any one character, except newlines.
^ Matches the beginning of a string, like the \A metacharacter.
$ Matches the end of a string, like the \Z metacharacter.
| Imposes either, or.

3.2.2.5.3 Examples of Defining Restricted Lists

The examples included in this section illustrate the results displayed in the user interface lists depending on how the Edit Restricted List Screen is completed. The restricted lists being defined use a metadata field defined to be an option list. Its master list values are the U.S. states in alphabetical order. The two dependencies include:

  • The items or expression entered into the text pane.

  • The Allow Java Regular Expressions check box (selected or unselected).

Example 1:

In this example, text values are entered into the text pane and the Allow Java Regular Expressions check box is not selected. In this case, the options 'NoState' and 'Carolina' are not included in the resulting list because they are not full names of states. Also notice that the order is maintained as typed into the text area.

If the following values are entered into the text pane:

  • Alabama

  • Minnesota

  • NoState

  • Utah

  • Carolina

The results displayed in the user interface list are:

  • Alabama

  • Minnesota

  • Utah

Example 2:

In this example, the same text values are entered into the text pane as in Example 1. However, the Allow Java Regular Expressions check box is selected.

If the following values are entered into the text pane:

  • Alabama

  • Minnesota

  • NoState

  • Utah

  • Carolina

The results displayed in the user interface list are:

  • Alabama

  • Minnesota

  • Utah

  • North Carolina

  • South Carolina

In this case, both 'North Carolina' and 'South Carolina' are included in the resulting list because they match the regular expression 'Carolina'.

Example 3:

In this example, the Allow Java Regular Expressions check box is selected and instead of entering similar text values (as in the previous examples) the ^ special character is used with alphabet characters.

In this case, there are two regular expressions. The first expression specifies choosing everything in the master list beginning with C and the second expression specifies choosing everything beginning with Al. Notice that the results order is dictated by how the list was entered in the text pane.

If the following values are entered into the text pane:

  • ^C

  • ^Al

Then the results displayed in the user interface list are:

  • California

  • Colorado

  • Connecticut

  • Alabama

  • Alaska

Example 4:

In this example, the same values are entered into the text pane as in Example 3. However, both values are entered on the same line and separated with the pipe ( | ) special character which is evaluated as 'or'. In this case, the expression retains the values in order because the list is filtered exactly once for values that begin with either Al or C.

If the following values are entered into the text pane:

  • ^C | ^Al

The following results are displayed in the user interface list:

  • Alabama

  • Alaska

  • California

  • Colorado

  • Connecticut

3.2.3 Content Profiles and Metadata Organization

This section covers these topics:

3.2.3.1 Using Rules to Group Metadata Fields

Metadata fields that display on the Check In, Update, Content Information, and Search pages can be added to a rule as a group and, optionally, the group can be labeled with an appropriate header. Editing the rule also lets you rearrange individual metadata fields within the group. The fields are displayed on the Check In, Update, Content Information, and Search pages according to how they are arranged in the group.

You establish metadata groups by selecting the Is group check box on the Add/Edit Rule Screens. Individual metadata fields are added to the group using the Fields Tab. Use the Up and Down buttons on this screen to rearrange the fields.

This section covers the following topics:

3.2.3.1.1 Reorganizing Metadata Fields

You can create a rule that groups specific metadata fields and determines how they are listed on the Check In, Update, Content Information, and Search pages. For example, Figure 3-7 shows a rule on the left that results in the metadata field list on the Check In page on the right. In this example, Content ID is the group leader because it is the first element in the group list. The metadata fields included after Content ID are the group associates.

Figure 3-7 Metadata Fields Generated from Rule

Surrounding text describes Figure 3-7 .

Figure 3-8 shows the same rule but the metadata fields in the group have been rearranged using the Up and Down buttons. This reorganization results in a different listing of the same metadata fields on the Check In page. In this case, Security Group becomes the group leader and the other fields are now the group associates.

Figure 3-8 Reorganized Metadata Fields

Surrounding text describes Figure 3-8 .
3.2.3.1.2 Metadata Field Conflicts Between Groups

It is possible that one or more metadata fields in a group could belong to groups in other rules that use grouped metadata fields. This could create conflicts about how the metadata fields are displayed on the Check In, Update, Content Information, and Search pages.

In Figure 3-9, a single profile contains three rules that have grouped metadata fields. Each group has one field that belongs to another group. In this situation, the system uses resolution rules to reconcile any conflicts. See "Resolution Rules" for details.

Figure 3-9 Profile with Rules Grouping Metadata Fields

Surrounding text describes Figure 3-9 .

Caution:

System evaluation and implementation of additional profile and global rules that contain one or more of these metadata fields can cause grouping conflicts. Depending on the priorities or precedences of the rules within a profile, some rules executed later may override earlier rules. This, in turn, can affect how grouped metadata fields are resolved. For more information about how rules are evaluated, refer to "Profile Rules" and "Global Rules".
3.2.3.1.3 Resolution Rules

The following rules are used sequentially to resolve metadata grouping conflicts:

  1. The first element in the list is the group leader.

  2. All elements following the first element are the group associates.

  3. If the group leader is not a group leader in another group listing, then assign any group associates to the group, below the group leader.

  4. If a group leader is a group associate in a prior group listing, then the new group listing is merged with the prior group listing as follows:

    1. Find the main group leader (the group leader in the prior group).

    2. Insert the new group associates after the group leader in the main group leader's group associates list.

  5. Make sure that no group associate has more than one group leader. If so, remove the associate from the prior group leader's list.

  6. If a grouping has a group associate that is a group leader in another later grouping, then this rule is invalid, an error is reported, and the rule is not evaluated. (If this were to be allowed, the result would be a non-group leader (a group associate) being promoted to a group leader.)

Example 1:

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: B,D,E is another metadata group

    WHERE: B is the group leader and D and E are group associates to B

  3. RESULT: A,B,D,E,C

Example 2:

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: A,D,E is another metadata group

    WHERE: A is the group leader and D and E are group associates to A

  3. RESULT: A,D,E,B,C

    Example 3:

Example 3:

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: C,B,D is another metadata group

    WHERE: C is the group leader and B and D are group associates to C

  3. RESULT: A,C,B,D

Example 4:

  1. IF: A,B is a metadata group

    WHERE: A is the group leader and B is a group associate to A

  2. AND: B,A,C is another metadata group

    WHERE: B is the group leader and A and C are group associates to B

  3. RESULT: Theoretically, this situation can be resolved to B,A,C but this makes the A,B grouping irrelevant. Therefore, to avoid confusion for other groupings, this is treated as an error case.

Example 5:

  1. IF: A,B,C is a metadata group

    WHERE: A is the group leader and B and C are group associates to A

  2. AND: D,A,E is another metadata group

    WHERE: D is the group leader and A and E are group associates to D

  3. RESULT: Error-it is impossible to resolve this grouping conflict.

3.2.3.2 Display Results of Reordered Metadata Fields

Content profiles can be used to reorder metadata fields on the Check In, Update, Content Information, and Search pages. Custom metadata fields as well as system-specific information fields can be reordered to suit your particular needs. This section provides more explicit information about the display results of reordered custom and system information fields on the Check In, Update, Content Information, and Search pages.

You can position metadata fields, as described in the following sections:

You can move metadata fields, as described in the following sections:

3.2.3.2.1 General Sequence of Grouped Metadata Fields on Content Server Pages

The positioning of grouped system and custom metadata fields on Content Server pages is determined by the priority of the first metadata field in the group. When you add a custom metadata field to the system, you establish its positioning sequence (field order).

You add custom metadata fields using theConfiguration Manager: Information Field Tab and assign the sequence number in the Order field on the Add/Edit Metadata Field Screen.

When a custom metadata field is the first field in a group, that group is positioned on the page according to the field order assigned to the custom metadata field. When a system metadata field is the first field in a group, that group is positioned according to their established precedence.

Depending on the specific Content Server page, additional system metadata fields may be included in the general display order. Or, some system metadata fields are not included. For example, the Search page displays the Release Date and Expiration Date system metadata fields but excludes Revision.

By default, the general order for system metadata fields is as follows:

  • Content ID (dDocName)

  • Type (dDocType)

  • Title (dDocTitle)

  • Author (dDocAuthor)

  • Security Group (dSecurityGroup)

  • Account (dDocAccount)

  • Revision (dRevLabel)

    Note:

    Generally, a group with a system metadata field as the first field are displayed in their default order. For example, if Author is the first field in a group of custom metadata fields, that group is displayed below any group that contains Content ID, Type, or Title as its first field.
3.2.3.2.2 Positioning Metadata Fields Within a Group

The section Using Rules to Group Metadata Fields, describes how you can define rules to conveniently group custom and system metadata fields on the Check In, Update, Content Information, and Search pages. In addition to grouping your metadata fields, you can order them to suit your application.

There are two options available to order metadata fields:

  • Option 1: Field Position

    You can use the Field Position list that provides three positioning options: top, middle, and bottom. This option is available when you are adding metadata fields to rules using the Add Rule Field Screen. This option works in a relative manner. For example, you might add the following metadata fields:

    • xRegion (Top position)

    • xSubDept (Bottom position)

    If you add xDept with a field position of Middle, it is added as follows:

    • xRegion (Top position)

    • xDept (Middle position)

    • xSubDept (Bottom position)

    If you then add xContinent with a field position of Top, it is added as follows:

    • xRegion (Top position)

    • xContinent (Top position)

    • xDept (Middle position)

    • xSubDept (Bottom position)

    Similarly, if you add xManager with a field position of Middle, it is added as follows:

    • xRegion (Top position)

    • xContinent (Top position)

    • xDept (Middle position)

    • xManager (Middle position)

    • xSubDept (Bottom position)

    For more information about the Field Position option, refer to the Field Position list feature on the "Add Rule Field Screen".

    Note:

    This ordering option produces these display results on the Check In, Update, Content Information, and Search pages if you have grouped the fields. That is, when you add the fields to a rule, you must select the Is Group check box on the Add/Edit Rule Screens.
  • Option 2: Up and Down buttons

    You can use the Up and Down buttons to reorder fields. This option is available when you are adding metadata fields to rules using the Fields Tab. This method is useful to reorder fields that have already been added, or to reorder fields that have been added with the same field position.

    For example, if you added three fields with a field position of Top, they are positioned in the order they were added to the rule. However, if one of the three field needs to be moved to the absolute top, you can use the Up button to achieve this. Similarly, if any field is not positioned properly when it was added, you can use the Up and Down buttons to more precisely re-position them.

3.2.3.2.3 Display Results of Grouped Metadata Fields on the Check In, Update, and Check In Selected Pages

The following rules specify how metadata groups are displayed on the Check in, Update, and Check in Selected pages.

  • If the first field in a group is a system field (such as Content ID, Type, Title, etc.), the group is always displayed above the Primary File field.

  • If automatic Content ID generation is disabled, then the Content ID field is always listed as the first field on the page followed by the remaining fields in the group. Also, if a separate group includes other system fields like Title and Type, that group is listed after the Content ID group but above the Primary File field.

  • If automatic Content ID generation is enabled, then the Content ID field functions like a custom metadata field with 1 as its field order. In this case, if Content ID is the first field in a group, then the group is displayed immediately below the Primary File and Alternate File fields. Also, the Revision system metadata field is displayed after the last field in the Content ID group. (Note that, by default, Revision is displayed below the Alternate File field.)

  • If the first field of a group is a custom metadata field, then the group is displayed in the order that is determined by the field order number of the lead metadata field in relation to the field order numbers of lead metadata fields in other groups. This is valid even if system metadata fields are grouped with custom metadata fields.

  • The Release Date and Expiration Date fields are always listed last on the page unless they are grouped with a custom metadata field that has a higher (i.e., smaller number) field order value. Or, if Release Date and Expiration Date are grouped with a system metadata field, then they are listed above the Primary File field.

3.2.3.2.4 Display Results of Grouped Metadata Fields on the Search Page

The following rules specify how metadata groups are displayed on the Search page.

  • The Content ID field is always positioned first unless it is part of a group and it is not the first field. However, if Content ID is the first field of a group, then that group is listed first.

  • If a system metadata field (other than Content ID) is the first field in a group, that group is listed after the Content ID field or Content ID group.

  • All other groups with custom metadata fields as the first fields are displayed after groups with system metadata fields as the lead fields. When groups have a custom metadata field as the first field, the ordering of these groups is determined by the field order numbers of the lead metadata fields of groups in relation to each other.

    Note:

    In order for a metadata field to be displayed on a search page, the Enable for Search Index must be set on the Add/Edit Metadata Field Screen.
3.2.3.2.5 Display Results of Grouped Metadata Fields on the Content Information Page

The following rules specify how metadata groups are displayed on the Content Information page.

  • The Content ID field is always positioned first unless it is part of a group and it is not the first field.

  • The Checked Out By, Status, and Formats fields are always listed at the bottom.

  • The Security Group field, or any group with Security Group as the first field, is listed above the Checked Out By, Status, and Formats fields. This is valid unless:

    • The account is disabled. If the account is enabled, then Security Group is displayed above the Checked Out By field. Security Group is displayed above the Account field.

    • The Security Group field is part of a group where it is not the first field, and the lead metadata field has a field order number that positions it above other custom metadata fields. In this case, the Security Group field is displayed in the order that is determined by the field order number of the group's lead metadata field.

  • The Release Date and Expiration Date fields are listed as part of the Revision History table at the bottom of the page.

  • All other groups with custom metadata fields as the first fields are displayed in the order that is determined by the field order numbers of the lead metadata fields of groups in relation to each other.

3.2.3.2.6 Display Results of Grouped Metadata Fields on the Folder Information Page

The following rules specify how metadata groups are displayed on the Folder Information page.

  • The Content ID field is not displayed unless it is part of a group. Currently, any group with Content ID as the first field is not displayed. You can counteract this by defining another system or custom metadata field in the group as the lead field.

  • All the groups are listed that have system metadata fields as their lead field (provided their assigned display attribute is Edit, Label, or Required). If any system or custom metadata field is assigned a Hidden or Excluded display attribute, it will not be displayed. For more information about the display attributes assigned to metadata fields, refer to the Type list feature on the "Add/Edit Rule Field 'name' Screen".

  • All other groups with custom metadata fields as the first fields are displayed in the order that is determined by the field order numbers of the lead metadata fields of groups in relation to each other.

3.2.3.2.7 Moving Custom Metadata Fields to a Position Above the Primary File Field

To force any custom metadata field to display above the Primary File field:

  1. Add the custom metadata field to a group that includes system metadata fields.

  2. Make the first field in the group a system metadata field. Group position is based on which system metadata field is the lead field.

3.2.3.2.8 Moving System Metadata Fields to a Position Below the Primary File Field

To force any system metadata field to display below the Primary File field:

  1. Add the desired system metadata field to a group that includes custom metadata fields.

  2. Ensure that the first field in the group is a custom metadata field.

    This ensures that the group is displayed below the Primary File field. The group is positioned based on the field order number of the lead field.

3.2.4 Managing Rules

The following tasks are included in rule management:

3.2.4.1 Creating a New Rule

To create a new rule:

  1. On the Rules tab of the Configuration Manager Application Page, click Add.

    The Add/Edit Rule Screens is displayed.

  2. Enter the name and description information about the new rule.

  3. Click OK.

The following list provides references to sections describing how to configure the new rule:

3.2.4.2 Editing an Existing Rule

To edit an existing rule:

  1. On the Rules tab of the Configuration Manager Application Page, select the rule to edit from the Rules list pane, and click Edit.

    The Add/Edit Rule Screens is displayed and the fields are populated with the previously set values for the selected rule.

  2. Edit the field values.

  3. Click OK.

3.2.4.3 Deleting an Existing Rule

To delete an existing rule:

  1. On the Rules tab of the Configuration Manager Application Page, select the rule to delete from the Rules list pane, and click Delete.

    You are asked to verify your decision to delete the rule.

  2. Click OK.

    The selected rule is removed.

3.2.4.4 Creating a New Global Rule

To create a global rule:

  1. Open the Add/Edit Profile Screen by adding a new rule or selecting an existing rule to edit. See "Creating a New Rule" or "Editing an Existing Rule".

  2. On the General tab, select the Is global rule with priority check box.

  3. Optionally, change the default priority number. By default, 10 is the priority number listed. For more information about how rules are evaluated and resolved, see "Profile Rules".

  4. Click OK.

3.2.4.5 Editing an Existing Global Rule

To edit an existing global rule:

  1. On the Rules tab of the Configuration Manager Application Page, select the global rule to edit from the Rules list pane, and click Edit.

    The Add/Edit Rule Screens is displayed and the fields are populated with the previously set values for the selected global rule.

  2. Edit the field values.

  3. Click OK.

3.2.4.6 Deleting an Existing Global Rule

To delete an existing global rule:

  1. On the Rules tab of the Configuration Manager Application Page, select the global rule to delete from the Rules list pane, and click Delete.

    You are asked to verify your decision to delete the rule.

  2. Click OK.

    The selected rule is removed.

3.2.4.7 Adding Metadata Fields to a Rule

To add metadata fields to a rule:

  1. Open the Add/Edit Rule Screens by adding a new rule/global rule or selecting an existing rule/global rule to edit.

  2. Open the Fields tab, and click Add.

    The Add Rule Field Screen is displayed.

  3. Select a metadata field from the Field Name option list.

  4. Select a general placement choice for the metadata field from the Field Position option list.

  5. Click OK.

    The Add/Edit Rule Field 'name' Screen is displayed.

  6. Enter the information about the metadata field.

  7. Click OK.

  8. For each metadata field to be added to the rule, repeat steps 2 through 7 above.

The following list provides references to sections describing how to configure the metadata rule:

3.2.4.8 Grouping Metadata Fields

To group metadata fields:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. On the General tab, select the Is group check box.

  3. Click OK.

    The Edit Rule 'name' screen closes.

3.2.4.9 Adding a Header to a Metadata Field Group

To include a label (header) to a metadata group:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. On the General tab, select the Has group header check box.

  3. Click the corresponding Edit button.

    The Edit Group Header Screen is displayed.

  4. Enter the text of the header and click OK.

    The header is displayed above the grouped metadata fields.

3.2.4.10 Defining a New Activation Condition

To add an activation condition to a rule:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. On the General tab, select the Use rule activation condition check box.

  3. Click the corresponding Edit button. The Edit Activation Condition Screen Tabs is displayed.

  4. Click Add. The Edit Activation Condition: Add Condition Screen is displayed.

  5. Enter the name of the activation condition in the Name field, and click OK. The General Tab is displayed.

  6. Enter the information using the General tab and Clauses tab to define the activation condition. Optionally, you can write custom Idoc Script using the Custom tab.

  7. Click OK.

3.2.4.11 Editing an Existing Activation Condition

To edit an existing activation condition:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. Click the Edit button that corresponds to the activation condition check box.

    The Edit Activation Condition Screen Tabs is displayed.

  3. On the Conditions tab, select the activation condition that you want to edit from the Conditions list.

  4. Edit the field values.

  5. Click OK.

3.2.4.12 Deleting an Existing Activation Condition

To delete an existing activation condition:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. Click the Edit button that corresponds to the activation condition check box.

    The Edit Activation Condition Screen Tabs is displayed.

  3. On the Conditions tab, select the activation condition to delete from the Conditions list.

  4. Click Delete.

    The activation condition is removed.

3.2.4.13 Defining the Attributes of a Metadata Field

You must assign the required attributes (field position and type) to each metadata field belonging to a rule. You can also define optional attributes that include a required message, a default value, derived value or a restricted list. For more detailed information about the attributes of metadata fields in rules, see "Metadata Fields and Attributes in Rules".

To define the attributes of a metadata field:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. Open the Fields tab, and click Add.

    The Add Rule Field Screen is displayed.

  3. Select a metadata field from the Field Name option list.

  4. Select a general placement choice for the metadata field from the Field Position option list.

  5. Click OK.

    The Add/Edit Rule Field 'name' Screen is displayed.

  6. Select a display type from the Type option list.

  7. If desired, enter a required message.

  8. Define the additional attributes by setting default values, derived values or a restricted list. For more detailed information, see:

  9. Click OK.

Setting a Metadata Field Default Value

To set a default value field attribute:

  1. On the Add/Edit Rule Field 'name' Screen, select the Use default value check box.

  2. Click the corresponding Edit button.

    The Edit Default Value: Conditions Tab is displayed.

  3. On the Conditions tab, click Add.

    The Edit Default Value: Add Condition Screen is displayed.

  4. Enter the name for this default value attribute and click OK.

    The Add Condition screen closes and the default attribute name is added to the Conditions list.

  5. Select a Field value and Operator from the option lists. Depending on the selected value from the Field list, the Value field provides:

    • An editable field to enter the data.

    • A choice list of appropriate options.

    • An editable field with a corresponding Select button.

  6. Enter or select a value for the upper Value field, as applicable:

    1. Click Select if:

      The Field value is Content ID, the Edit Default Value: Select Field Screen is displayed.

      The Field value is Author, the User View Screen is displayed.

    2. Use the filters as desired to select content.

    3. Click OK.

    The Content Item View Screen or User View Screen closes and the selected content value is added to the upper Value field on the default value Conditions tab.

  7. Click Add.

    The statement is added to the expression pane.

  8. Click Compute.

    The Edit Default Value: Select Field Screen is displayed.

  9. If the field is linked to a schema view, you can select a column. Otherwise, click OK.

    The Select Field screen closes and the computed value is added to the lower Value field on the default value Conditions tab.

  10. Click OK.

    The Edit Default Value screen closes and the Idoc Script statement is displayed in the default value text pane on the Add Rule Field <name> screen.

  11. If you are finished adding metadata field attributes, click OK. Otherwise, continue to include additional attributes. See "Setting a Metadata Field Derived Value" and "Setting a Metadata Field Restricted List Condition".

Setting a Metadata Field Derived Value

To set a derived value field attribute:

  1. On the Add/Edit Rule Field 'name' Screen, select the Is derived field check box.

  2. Click the corresponding Edit button.

    The Edit Derived Value: Conditions Tab is displayed.

  3. On the Conditions tab, click Add.

    The Edit Derived Value: Add Condition Screen is displayed.

  4. Enter the name for this derived value attribute and click OK.

    The Add Condition screen closes and the derived attribute name is added to the Conditions list.

  5. Select a Field value and Operator from the option lists. Depending on the selected value from the Field list, the Value field provides:

    • An editable field to enter the data.

    • A choice list of appropriate options.

    • An editable field with a corresponding Select button.

  6. Enter or select a value for the upper Value field, as applicable:

    1. Click Select if:

      The Field value is Content ID, the Edit Derived Value: Select Field Screen is displayed.

      The Field value is Author, the User View Screen is displayed.

    2. Use the filters as desired to select content.

    3. Click OK.

    The Content Item View Screen or User View Screen closes and the selected content value is added to the upper Value field on the default value Conditions tab.

  7. Click Add.

    The statement is added to the expression pane.

  8. Click Compute.

    The Edit Derived Value: Select Field Screen is displayed.

  9. If the field is linked to a schema view, you can select a column. Otherwise, click OK.

    The Select Field screen closes and the computed value is added to the lower Value field on the derived value Conditions tab.

  10. Click OK.

    The Edit Derived Value screen closes and the Idoc Script statement is displayed in the default value text pane on the Add Rule Field <name> screen.

  11. If you are finished adding metadata field attributes, click OK. Otherwise, continue to include additional attributes. See "Setting a Metadata Field Default Value" and "Setting a Metadata Field Restricted List Condition".

Setting a Metadata Field Restricted List Condition

To use a restricted list for the metadata field:

  1. On the Add/Edit Rule Field 'name' Screen, select the Has restricted list check box.

  2. Click the corresponding Edit button.

    The Edit Restricted List Screen is displayed.

  3. To use a list of values that are directly associated with rules, select the Is filtered list option.

    Otherwise, if you want to use a list of specific values, select the Is strict list option and enter the specific items in the Restricted value text pane.

  4. Click OK.

    The Edit Restricted List screen closes and if you used the strict list option, the items are displayed in the restricted list text pane on the Add Rule Field <name> screen.

3.2.4.14 Editing the Attributes of a Metadata Field

To edit the attributes of a metadata field:

  1. Open the Add/Edit Rule Screens. See step 0 in the "Adding Metadata Fields to a Rule" procedure.

  2. Open the Fields tab, and select the metadata field whose attributes you want to edit.

  3. Click Edit.

    The Add/Edit Rule Field 'name' Screen is displayed.

  4. Click the corresponding Edit button of the attribute you want to edit.

  5. For either the default value or derived value, select the value to edit in the Conditions text pane.

    1. Select the desired new Field and/or Operator field values.

    2. To edit the upper Value field value without deleting and redefining the clause:

      o Highlight the clause in the Clause pane.

      o Edit the value in the upper Value field.

      o Click Update.

      The new value is updated and displayed in the Clause pane.

    3. Click Compute.

    4. Click OK.

      The Edit Default/Derived Value screen closes and the revised values are displayed in the default/derived value text pane on the Edit Rule Field <name> screen.

  6. For the restricted list attribute,

    1. On the Edit Restricted List screen, select the desired list option and edit the text pane as necessary.

    2. Click OK.

      The Edit Restricted List screen closes and the revised restricted list information is displayed in the restricted list text pane on the Edit Rule Field <name> screen.

  7. Click OK.

    The Edit Rule Field <name> screen closes.

3.2.4.15 Setting the Display of a Required Field

Two configuration variables control how required metadata fields appear on the Check In page. These variables must be manually set in the IntradocDir/config/config.cfg file. For more information, see the Oracle Fusion Middleware Idoc Script Reference Guide.

  • To use red lettering for a required field, use the following configuration variable and value:

    StyleForRequiredFields=requiredField
    
  • To mark the required field with any symbol, use the following configuration variable and value:

    NotationForRequiredFields=*
    

    Note: In this example, an asterisk is used to mark the required fields.

3.2.5 Content Profile Triggers

This section covers the following topic:

3.2.5.1 About Triggers

A trigger field is a metadata field that is defined on the Configuration Manager: Profiles Tab. If a document matches a trigger value for a profile, then that profile is evaluated for the document. There can be an unlimited number of profiles, but only one trigger value per profile.

For example, if the trigger field is dDocType, Profile1 can use the trigger value of ADACCT and Profile2 can use the trigger value of ADSALES. See "Add Profile Screen" for details.

The selected trigger field must satisfy the following criteria:

  • It must be an option list metadata field. The metadata fields that are defined as option lists are included in the list for selecting the trigger field. Refer to the "Add Profile Screen".

  • After the trigger field has been defined, it cannot be deleted from the system.

  • It is possible to undefine or disable the trigger field. The administrator can set the trigger field back to none specified. This disables all profiles. See "Disabling a Profile Trigger Field".

  • The trigger field may be changed. See "Disabling a Profile Trigger Field". When it is changed, profiles may become invalid and it is the administrator's responsibility to resolve the situation. However, user interface hints are provided concerning which profiles are invalid.

    Note:

    Although you create rules before you create triggers and profiles, it is necessary to know what your trigger will be prior to creating rules.

3.2.5.2 Selecting a Profile Trigger Field

Only one trigger field can be selected for each content server instance.

To select or change the current profile trigger field:

  1. On the Profiles tab of the Configuration Manager, click Select.

    The Edit Trigger Field Screen is displayed.

  2. Select a new trigger field from the option list in the Field Name field.

  3. Click OK.

    Note:

    If you change the trigger field after one or more profiles have already been created, the new trigger field could cause the existing profiles to become invalid.

3.2.5.3 Disabling a Profile Trigger Field

To completely disable the trigger field and essentially disable all profiles as well:

  1. On the Profiles tab of the Configuration Manager Application Page, click Select.

    The Edit Trigger Field Screen is displayed.

  2. Select none specified from the option list in the Field Name field.

  3. Click OK.

3.2.6 Managing Content Profiles

This section covers these topics:

3.2.6.1 Creating and Defining a New Profile

To create a new profile:

  1. On the Profiles tab of the Configuration Manager Application Page, click Add.

    The Add Profile Screen is displayed.

  2. Enter the name of the new profile in the Profile Name field.

  3. Click OK.

    The Add/Edit Profile Screen is displayed.

  4. Enter the information about the new profile on the Add Profile 'name' screen.

  5. Click Add to include rules in the new profile.

    The Add Rule Screen is displayed.

    Note:

    Rules cannot be added to the profile until you have created and defined them using the Configuration Manager: Rules Tab.
  6. Select rules from the option list and assign them a general placement priority value.

  7. Click OK.

    The new profile is included in the Profiles list on the Profiles tab.

3.2.6.2 Editing an Existing Profile

To edit an existing profile:

  1. On the Profiles tab of the Configuration Manager Application Page, select the profile you want to edit from the Profiles list pane, and click Edit.

    The Add/Edit Profile Screen is displayed and the fields are populated with the previously set values for the selected profile.

  2. Edit the field values.

  3. Click OK.

3.2.6.3 Deleting an Existing Profile

To delete an existing profile:

  1. On the Profiles tab of the Configuration Manager Application Page, select the profile to delete, and click Delete.

    You are asked to verify your decision to delete the profile.

  2. Click OK.

    The selected profile is removed.

3.2.6.4 Managing the Rules in a Profile

Managing the rules that belong to a profile means that, if necessary, you can add, strategically prioritize, or delete the profile's rules as follows:

3.2.6.4.1 Adding Rules to an Existing Profile

To add rules to an existing profile:

  1. On the Profiles tab of the Configuration Manager Application Page, select the appropriate profile from the Profiles list, and click Edit.

    The Add/Edit Profile Screen is displayed.

  2. Click Add.

    The Add Rule Screen is displayed.

  3. Select a rule from the Name option list.

  4. Select a general placement choice for the rule from the Rule Priority option list.

  5. Click OK.

    The selected rule is added to the Rules list.

3.2.6.4.2 Prioritizing Rules in an Existing Profile

To prioritize rules in an existing profile:

  1. On the Add/Edit Profile Screen, select the rule to reposition.

  2. Click Up to move the rule to increase the rule's priority or click Down to decrease the rule's priority.

    The rule's placement is shifted and its priority will be appropriately adjusted in the evaluation process.

3.2.6.4.3 Deleting Rules from an Existing Profile

To delete rules from an existing profile:

  1. On the Add/Edit Profile Screen, select the rule to delete.

  2. Click Delete.

    The selected rule is removed from the profile.

3.2.6.5 Previewing a Profile

To preview a profile for verification or review:

  1. On the Profiles tab of the Configuration Manager Application Page, select the profile to be previewed from the Profiles list, and click Preview.

    The Preview Profile Screen is displayed.

  2. To review the compiled results of the current profile, do not change any field values on the Preview Profile screen. Click Compute results.

    The Preview Results Screen is displayed.

  3. Review the computed results, and click OK.

3.2.6.6 Troubleshooting a Previewed Profile

In addition to previewing the compiled results of your profile, the Preview Profile Screen is also used to troubleshoot invalid profiles and perform analysis on any profile.

Troubleshooting using what-if scenarios is an iterative process, composed of trying combinations of inputs to evaluate the profile's rules. In addition to using different input values, you can include filtered selections of documents.

Changing the different criteria (with or without filters) and computing the results allows you see how various input combinations affect the evaluation of rules. When the system evaluates the profile's rules, the computed results are displayed either as script string statements (SQL or Idoc Script) in a standard dialog text pane or as simulated Check In or Search pages (if you select the On Request option as the Event field value). Using the flexibility of the what-if analysis process helps you debug and optimize your profiles.

3.2.6.6.1 Using Inputs and Filters to Perform What-If Analysis

To perform what-if scenarios using diverse combinations of inputs and filters:

  1. On the Profiles tab of the Configuration Manager Application Page, select the profile to be reviewed and tested from the Profiles list, and click Preview.

    The Preview Profile Screen is displayed.

  2. Select field values, as applicable, from the Event, Action, and Is workflow option lists.

  3. To include filtered choices for the Content ID field, click the corresponding Select button.

    The Content Item View Screen is displayed.

  4. Select content item filter options, as applicable, and click OK. You are returned to the Preview Profile screen.

  5. To include filtered choices for the User Name field, click the corresponding Select button.

    The User View Screen is displayed.

  6. Select user filter options, as applicable, and click OK. You are returned to the Preview Profile screen.

    Note:

    o evaluate the rules using the new inputs and review the results as script string statements in a dialog, see "Evaluating the Results as Script Strings in a Dialog".

    To evaluate the rules using the new inputs and review the metadata results as a simulated Check In or Search page in a dialog, see "Evaluating Results as a Simulated Page in a Browser Window".

3.2.6.6.2 Evaluating the Results as Script Strings in a Dialog

To view the evaluated rules as coded statements:

  1. Perform a what-if analysis. See "Using Inputs and Filters to Perform What-If Analysis".

  2. Click Compute results.

    The Preview Results Screen is displayed and the coded statements from the evaluated rules are shown in the dialog text pane.

  3. Review the computed results, and click OK to return to the Preview Profile screen and continue testing additional what-if profile scenarios.

3.2.6.6.3 Evaluating Results as a Simulated Page in a Browser Window

To view the evaluated rules and resulting metadata fields as they would display on Check In or Search pages for end users:

  1. On the Profiles tab of the Configuration Manager Application Page, select the profile to be reviewed and tested from the Profiles list, and click Preview.

    The Preview Profile Screen is displayed.

    Note:

    If you have selected the On Request option in the Event field on the Preview Profile screen, then the Show button opens a browser window to display a reconstructed image of the page showing the processed metadata field results. Also, previews performed in the browser window do not use a User Name field value.
  2. In the Event field, select the On Request option.

  3. Select field values, as applicable, from the Action and Is workflow option lists.

  4. To include filtered choices for the Content ID field, see steps 3 and 4 in the section "Using Inputs and Filters to Perform What-If Analysis".

  5. Click Show on the Preview Profile Screen.

    The system launches a browser window that displays the resulting metadata fields in a simulated Check In or Search page. This window provides a graphic view or what the end user will see.

  6. Review the computed results and to continue testing additional what-if scenarios, close the browser window to return to the Preview Profile screen.

3.2.7 Content Profile Examples

These profile examples are included to help you develop useful profiles:

3.2.7.1 Department-Based Content Profile

This example shows how to plan and create a department-based profile that includes one global rule and one regular profile rule.

The goal is to control how the metadata fields governed by the rules are displayed on the Check In, Update, Content Information, and Search pages. Ideally, only department-specific fields are displayed. This minimizes the number of metadata fields that users see.

This example creates the applicable rules first and then the profile because the rules are added to the profile during the process of creating the actual profile.

This example is divided into the following main steps:

  • Create a global rule with the characteristics:

    • Ensure that all new and updated content items that are checked in have comments associated with them. The optional comments metadata field is revised to be a required field.

    • Allow the content item title metadata field to be editable.

    See "Create the Profile Rule".

  • Create a profile rule with the following characteristics:

    • Provide a default value for the comments metadata field but also allow it to be editable. The default message is triggered by marketing-specific documents.

    • Provide default values that are read-only text for the publish type and revision label metadata fields.

    See "Create the Profile Rule".

  • Create a department-based profile with the characteristics:

    • Organize the metadata fields that are hidden or displayed on the Check In, Update, Content Information, and Search pages.

    • Display only those fields that are relevant to the marketing department.

    • Group selected metadata fields using a marketing-based group heading.

    See "Create the Department-Based Profile".

3.2.7.1.1 Create the Global Rule

To create the global rule:

  1. Open the Rules tab on the Configuration Manager Application Page, and select Add.

    The Add/Edit Rule Screens is displayed.

  2. On the General tab, enter the name of the global rule in the Name field (for example, CmtsRqd).

  3. Optionally, enter a description for the global rule.

  4. Select the Is global rule with priority check box. (You can optionally change the priority number.)

  5. Add and define the Comments metadata field as follows:

    1. On the Fields tab, click Add.

      The Add Rule Field Screen is displayed.

    2. Select Comments from the Field Name option list.

    3. Select a general position from the Field Position option list (for example, top).

    4. Click OK.

      The Add/Edit Rule Field 'name' Screen is displayed.

    5. Select the Required display type from the Type option list (to ensure that users must enter a comment about the content item being checked in).

    6. Enter a statement in the Required Message field. (This is optional for all rule field types except the Required type.)

    7. Select the Use default value check box and click the corresponding Edit button.

      The Edit Default Value: Conditions Tab is displayed.

    8. On the Conditions tab, click Add.

      The Edit Default Value: Add Condition Screen is displayed.

    9. Enter the name of the field condition (for example, UserMsg).

    10. Click OK.

      The Add Condition screen closes and the clause-generating fields display on the lower pane of the Conditions tab.

    11. Enter a short statement in the lower Value field, at the far bottom of the screen (near the Compute button). This statement will be the default value for the Comment field.

    12. Click OK.

      The Edit Default Value screen closes and the default value Idoc Script clause for the UserMsg field condition is added to the Default Value text pane.

    13. Click OK.

      The Add Rule Field screen closes and the Comments metadata field is added to the Fields list.

  6. Add and define the Document Title metadata field as follows:

    1. On the Fields tab of the Add/Edit Rule screen, click Add.

    2. Select Title from the Field Name option list.

    3. Select a general position from the Field Position option list (for example, bottom).

    4. Click OK.

    5. Select the Edit display type from the Type option list (to allow this metadata field to be editable on the Check In and Search pages).

    6. Optionally, enter a note in the Required Message field.

    7. Click OK.

      The Title metadata field is added to the Fields list.

  7. Click OK.

    The Add/Edit Rule screen closes.

3.2.7.1.2 Create the Profile Rule

To create the profile rule:

  1. On the Rules tab, select Add.

  2. On the General tab, enter the name of the profile rule in the Name field (for example, DefaultMktComment).

  3. Optionally, enter a description for the profile rule.

  4. Select the Is group check box.

  5. Select the Has group header check box, and click the corresponding Edit button.

    The Edit Group Header Screen is displayed.

  6. Enter the text to use as the header for the grouped metadata fields (for example, Marketing-Specific Information).

  7. Click OK.

  8. Add and define the Comments metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Comments from the Field Name option list.

    3. Select a general position from the Field Position option list (for example, top).

    4. Click OK.

    5. Select the Edit display type from the Type option list (to allow this metadata field to be editable on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a note in the Required Message field.

    7. Select the Use default value check box, and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, CurrentMktgDocs).

    10. Click OK.

    11. Enter These are Current Marketing Docs into the lower Value field at the bottom of the screen (near the Compute button).

    12. Click OK.

      The default value Idoc Script clause for the 7.5MktgDocs field condition is added to the Default Value text pane.

    13. Click OK.

      The Comments metadata field is added to the Fields list.

  9. Add and define the Publish Type metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Publish Type from the Field Name option list.

    3. Select a general position from the Field Position option list (for example, middle).

    4. Click OK.

    5. Select the Label display type from the Type option list (to make this a read-only metadata field on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a note in the Required Message field.

    7. Select the Use default value check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, MktgDocsOnly).

    10. Click OK.

    11. Enter @dDocName into the lower Value field at the bottom of the screen (near the Compute button).

    12. Click OK.

      The default value Idoc Script clause for the MktgDocsOnly field condition is added to the Default Value text pane.

    13. Click OK.

      The Publish Type metadata field is added to the Fields list.

  10. Add and define the Revision Label metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Revision from the Field Name option list.

    3. Select a general position from the Field Position option list (for example, bottom).

    4. Click OK.

    5. Select the Label display type from the Type option list (to make this a read-only metadata field on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a note in the Required Message field.

    7. Select the Use default value check box.

    8. Click OK.

      The Revision Label metadata field is added to the Fields list.

  11. Click OK.

    The Add/Edit Rule screen closes.

3.2.7.1.3 Create the Department-Based Profile

To create a department-based profile:

  1. Open the Profiles tab on the Configuration Manager Application Page and click Select.

    The Add Profile Screen is displayed.

  2. Select Type from the Field Name option list.

  3. Click OK.

  4. Click Add on the Profiles tab.

    The Add Profile Screen is displayed.

  5. Enter the name of the profile (for example, MktgDoc).

  6. Click OK.

    The Add/Edit Profile Screen is displayed.

  7. Enter the profile description in the Description field (for example, Current Mktg docs).

  8. Enter a label for the profile that clearly identifies its use (for example, MarketingSpecific).

  9. Select ADMKT (or an equivalent marketing option) from the Trigger option list.

  10. Click Add to include the rules in this profile.

    The Add Rule Screen is displayed.

  11. Select the DefaultMktComment rule from the Name option list.

  12. Select a general priority placement from the Rule Priority option list (for example, top).

  13. Click OK.

  14. Click Add.

  15. Click OK.

  16. Click OK.

    The Add Profile screen closes and the profile is added to the list of profiles on the Profiles tab.

3.2.7.2 Black-Hole Check In Profile for Resumes

This example shows how to plan and create a black-hole check in profile used to submit resumes to Human Resources.

The goal is to restrict the visible metadata fields available on the Check In, Update, Content Information, and Search pages when using this profile. After a resume is initially checked in, the derived settings for all the potentially searchable metadata fields prevent unauthorized users from retrieving the document. This example creates the applicable rules first and then the profile because the rules are added to the profile during the process of creating the actual profile.

This example is based on the default metadata fields displayed using a non-customized Content Server instance. The visible metadata fields in this profile are limited to Type, Primary File, Alternate File, and Comments. The Type field uses a read-only label. On submission the value is reset to an HR-accessible value to ensure confidentiality of the document. Only the Comments field is editable. The remaining metadata fields are hidden and on submission also have their values reset. In this example, the hidden metadata fields include Title, Author, Security Group, Content ID, Revision, Release Date, and Expiration Date.

Note:

If selected, both the Hidden and Excluded display attributes conceal the defined metadata field. Using the Hidden type has the advantage of allowing the field value to remain on the source page. Thus, the contributor does not see the Hidden fields when checking in the document, but the assigned field values are still visible to an authorized viewer. The Excluded type precludes the field values on the source page.

Note:

In a black-hole check in profile, it is not advisable to depend on the Exclude non-rule fields check box to hide unnecessary metadata fields. Selecting this check box suppresses the display of all metadata fields that do not belong to the profile's rules. Therefore, contributors would not see these fields. However, it would not prevent default values from being assigned and subsequently stored on the source page. It would then be possible for unauthorized users to find a black-hole document by searching on the excluded metadata fields.

This example is divided into the following main steps:

  • Create a profile rule that:

    • Hides non-essential metadata fields and does not display them on the Check In, Update, Content Information, and Search pages.

    • Resets the default values of each hidden metadata field to ensure that unauthorized users cannot search and retrieve documents using the hidden fields.

    See "Create a Profile Rule for the Hidden Metadata Fields".

  • Create a profile rule that:

    • Allows the display of specific metadata fields related to checking in a resume.

    • Resets the values of each visible metadata field to ensure that unauthorized users cannot search and retrieve documents using these fields.

    See "Create a Profile Rule for the Visible Metadata Fields".

  • Create a black-hole check in profile that:

    • Restricts the metadata fields that are hidden or displayed on the Check In, Update, Content Information, and Search pages.

    • Displays only those fields that are relevant to an employee who is checking in a resume for an internal company position.

    See "Create the Black-Hole Check In Profile for Resumes".

3.2.7.2.1 Create a Profile Rule for the Hidden Metadata Fields

To create a profile rule for hidden metadata fields:

  1. Open the Rules tab on the Configuration Manager Application Page, and select Add.

    The Add/Edit Rule Screens is displayed.

  2. On the General tab, enter the name of the rule in the Name field (for example, NoExtraFields).

  3. Optionally, enter a description for the global rule.

  4. Add and define the Title metadata field as follows:

    1. On the Fields tab, click Add.

      The Add Rule Field Screen is displayed.

    2. Select Title from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

      The Add/Edit Rule Field 'name' Screen is displayed.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

      The Edit Derived Value: Conditions Tab is displayed.

    8. On the Conditions tab, click Add.

      The Edit Derived Value: Add Condition Screen is displayed.

    9. Enter the name of the field condition (for example, HRsEyesOnly).

    10. Click OK.

      The Add Condition screen closes and the clause-generating fields display on the lower pane of the Conditions tab.

    11. In the lower Value field, enter a confidential string (for example, No specific title). This will help to prevent unauthorized users from using the Title metadata field to search for and retrieve the documents checked in using this profile.

    12. Click OK.

      The Edit Derived Value screen closes and the computed Idoc Script clause is added to the derived field text pane.

    13. Click OK.

      The Add Rule Field screen closes and the Title metadata field is added to the Fields list.

  5. Add and define the Author metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Author from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly2).

    10. Click OK.

    11. Select Author from the Field option list.

    12. Select Matches from the Operation option list.

    13. Click Select.

      The User View Screen displays. Select the applicable user name. (For example, select an HR employee or whoever is authorized to view the documents checked in using this profile. This will help ensure that unauthorized users cannot search and retrieve these documents using the Author metadata field.)

    14. Click OK.

      The User View screen closes and the selected user is entered in the upper Value field.

    15. Click Add.

      The clause is added to the clause pane.

    16. Click OK.

    17. Click OK.

  6. Add and define the Security Group metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Security Group from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly3).

    10. Click OK.

    11. Select Security Group from the Field option list.

    12. Select Matches from the Operation option list.

    13. Select an applicable choice from the Value option list.

      For example, select HR or any other department that is authorized to view the documents checked in using this profile. This helps ensure that unauthorized users cannot search and retrieve these documents using the Security Group metadata field.

    14. Click Add.

    15. Click OK.

    16. Click OK.

  7. Add and define the Content ID metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Content ID from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly4).

    10. Click OK.

    11. Select Content ID from the Field option list.

    12. Select Begins With from the Operation option list.

    13. Enter a confidential string or, optionally, click Select.

      The Edit Derived Value: Select Field Screen is displayed. You can select a content item from the list. However, to ensure greater security, you should enter a unique string (for example, Res). This helps ensure that unauthorized users cannot search and retrieve these documents using the Content ID metadata field.

    14. Click OK (if you selected a content item from the Content Item View Screen).

    15. Click Add.

    16. Click OK.

    17. Click OK.

  8. Add and define the Revision metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Revision from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly5).

    10. Click OK.

    11. Select Revision from the Field option list.

    12. Select Begins With from the Operation option list.

    13. Enter a confidential string in the upper Value field (for example, Res). This helps ensure that unauthorized users cannot search and retrieve these documents using the Revision metadata field.

    14. Click Add.

    15. Click OK.

    16. Click OK.

  9. Add and define the Release Date metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Release Date from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly6).

    10. Click OK.

    11. In the lower Value field, enter a confidential string (for example, No specific release date). This will help to prevent unauthorized users from using the Release Date metadata field to search for and retrieve the documents checked in using this profile).

    12. Click OK.

    13. Click OK.

  10. Add and define the Expiration Date metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Expiration Date from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Hidden from the Type option list (to ensure that this metadata field does not display on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Is derived field check box and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, HRsEyesOnly7).

    10. Click OK.

    11. In the lower Value field, enter a confidential string (for example, No specific expiration date). This will help to prevent unauthorized users from using the Expiration Date metadata field to search for and retrieve the documents checked in using this profile).

    12. Click OK.

    13. Click OK.

  11. Click OK.

    The Add Rule screen closes.

3.2.7.2.2 Create a Profile Rule for the Visible Metadata Fields

To create a profile rule for visible metadata fields:

  1. On the Rules tab, select Add.

  2. On the General tab, enter the name of the profile rule in the Name field (for example, VisibleFields).

  3. Optionally, enter a description for the profile rule.

  4. Add and define the Type metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Type from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Label from the Type option list (to make this a read-only metadata field on the Check In, Update, Content Information, and Search pages).

    6. Optionally, enter a statement in the Required Message field.

    7. Select the Use default value check box, and click the corresponding Edit button.

    8. On the Conditions tab, click Add.

    9. Enter the name of the field condition (for example, ResumeType).

    10. Click OK.

    11. In the lower Value field, enter Resume.

    12. Click OK.

    13. Select the Is derived field check box and click the corresponding Edit button.

    14. On the Conditions tab, click Add.

    15. Enter the name of the field condition (for example, ResumeType2).

    16. Click OK.

    17. In the lower Value field, select an appropriate document type from the Value option list (for example, HRresumes).

    18. Click OK.

    19. Click OK.

  5. Add and define the Comments metadata field as follows:

    1. On the Fields tab, click Add.

    2. Select Comments from the Field Name option list.

    3. Select a general position from the Field Position option list.

    4. Click OK.

    5. Select Edit from the Type option list (to allow this metadata field to be editable on the Check In, Update, Content Information, and Search pages).

    6. Select the Use default value check box and click the corresponding Edit button.

    7. On the Conditions tab, click Add.

    8. Enter the name of the field condition (for example, PositionAppliedFor).

    9. Click OK.

    10. In the lower Value field, enter an appropriate statement (for example, Please specify the position title).

    11. Click OK.

    12. Click OK.

    13. Click OK.

3.2.7.2.3 Create the Black-Hole Check In Profile for Resumes

To create the black-hole checkin profile:

  1. Open the Profile tab on the Configuration Manager Application Page and click Select.

    The Add Profile Screen is displayed.

  2. Select Type from the Field Name drip down option list.

  3. Click OK.

  4. Click Add on the Profiles tab.

    The Add Profile Screen is displayed.

  5. Enter the name of the profile (for example, BlackHoleResumeCheckIn).

  6. Click OK.

    The Add/Edit Profile Screen is displayed.

  7. Enter the profile description in the Description field (for example, For internal user resumes only).

  8. Select HRresumes (or the equivalent option) from the Trigger option list.

  9. Click Add to include the rules in this profile.

    The Add Rule Screen is displayed.

  10. Select the NoExtraFields rule from the Name option list.

  11. Select a general priority placement from the Rule Priority option list.

  12. Click OK.

  13. Click Add.

  14. Select the VisibleFields rule from the Name option list.

  15. Select a general priority placement from the Rule Priority option list.

  16. Click OK.

  17. Click OK.

    The Add Profile screen closes and the profile is added to the list of profiles on the Profiles tab.

3.2.7.3 Global Rule to Restrict Content Check-In Based on User Role

This example shows how to create a global rule that can validate metadata fields when users check in content. The global rule validates the data in a request, and returns an error message if the data is incorrect. Specifically, this example shows how to allow only an administrator to check in content that specifies ADACCT as the Content Type.

3.2.7.3.1 Enable Content Server to Issue a Fatal Error Upon a Global Rule Violation
  1. In a text editor, open the config.cfg file:

    IntradocDir/config/config.cfg

  2. Add the following configuration setting:

    IsDpSubmitErrorFatal=true
    
  3. Close and save the file.

  4. Restart the Content Server.

3.2.7.3.2 Create a Global Rule to Restrict Content Type Check-Ins

This global rule validates the value for dDocType and ensures that an administrator is checking in an ADACCT document. However, the rule is configured to affect only the Check In and Update pages.

  1. Open the Rules tab on the Configuration Manager Application Page, and click Add.

    The Add/Edit Rule Screens is displayed.

  2. On the General tab, enter the name of the global rule in the Name field (for example, FailOnCheckInError).

  3. Optionally, enter a description for the global rule.

  4. Select the Is global rule with priority check box. (You can optionally change the priority number.)

  5. Select the Use rule activation condition check box and click the corresponding Edit button.

    The Edit Activation Condition Screen Tabs is displayed.

  6. Click Add.

    The Edit Activation Condition: Add Condition Screen is displayed.

  7. Enter the name of the condition in the Name field (for example, CheckIn).

  8. Click OK.

    The Add Condition screen closes and the General Tab is displayed. The clause-generating tabs display on the lower pane.

  9. Select the Use event check box.

  10. Select the On Submit check box.

  11. Select the Use action check box.

  12. Select the Check in new, Check in selected, and Content update check boxes.

  13. Click OK.

    The Edit Activation Condition screen closes and the activation condition clause is entered into the Use rule activation condition text pane.

  14. Click the Fields tab.

    The Add/Edit Rule Field 'name' Screen is displayed.

  15. Click Add.

    The Add Rule Field Screen is displayed.

  16. Select Type from the Field Name list.

  17. Optionally, select a general position form the Field Position list.

  18. Click OK.

    The Add/Edit Rule Field 'name' Screen is displayed.

  19. Select the Is derived field check box and click the corresponding Edit button.

    The Edit Derived Value: Conditions Tab is displayed.

  20. Click the Custom tab.

    The Edit Derived Value: Custom Tab is displayed.

  21. Select the Custom check box and enter the following Idoc Script:

    <$if dDocType like "ADACCT" and not userHasRole("admin")$>
    <$abortToErrorPage("Only administrators can use ADACCT.")$>
    <$endif$>
    
  22. Click OK.

  23. Click OK.

  24. Click OK.

    The rule is added to the list of Rules.

3.2.7.4 Global Rule to Restrict Content Type Metadata Changes

This example shows how to create a global rule that can validate metadata fields when users check in content. The global rule validates the data in a request, and returns an error message if the data is incorrect. Specifically, this example shows how to allow only an administrator to change the content type of a checked-in document.

3.2.7.4.1 Enable Content Server to Issue a Fatal Error Upon a Global Rule Violation
  1. In a text editor, open the config.cfg file:

    IntradocDir/config/config.cfg

  2. Ensure that you set this configuration earlier:

    IsDpSubmitErrorFatal=true
    
  3. Close and save the file.

  4. Restart the Content Server.

3.2.7.4.2 Create a Global Rule to Restrict Content Type Changes

This global rule validates the value for dDocType and ensures that an administrator is changing the content type of a checked-in document. However, it is configured to affect only the Check In page.

  1. Open the Rules tab on the Configuration Manager Application Page and click Add.

    The Add/Edit Rule Screens is displayed.

  2. On the General tab, enter the name of the global rule in the Name field (for example, FailOnCheckInError).

  3. Optionally, enter a description for the global rule.

  4. Select the Is global rule with priority check box. (You can optionally change the priority number.)

  5. Select the Use rule activation condition check box and click the corresponding Edit button.

    The Edit Activation Condition Screen Tabs is displayed.

  6. Click Add.

    The Edit Activation Condition: Add Condition Screen is displayed.

  7. Enter the name of the condition in the Name field (for example, CheckIn).

  8. Click OK.

    The Add Condition screen closes and the Edit Activation Condition is displayed. The clause-generating tabs display on the lower pane.

  9. Select the Use event check box.

  10. Select the On Submit check box.

  11. Select the Use action check box.

  12. Select the Content update check box.

  13. Click OK.

    The Edit Activation Condition screen closes and the activation condition clause is entered into the Use rule activation condition text pane.

  14. Click the Fields tab.

    The Fields Tab is displayed.

  15. Click Add.

    The Add Rule Field Screen is displayed.

  16. Select Type from the Field Name list.

  17. Optionally, select a general position form the Field Position list.

  18. Click OK.

    The Add/Edit Rule Field 'name' Screen is displayed.

  19. Select the Is derived field check box and click the corresponding Edit button.

    The Edit Derived Value: Conditions Tab is displayed.

  20. Click the Custom tab.

    The Edit Derived Value: Custom Tab is displayed.

  21. Select the Custom check box and enter the following Idoc Script:

    <$oldType = getValue("DOC_INFO", "dDocType")$>
    <$newType = getValue("#local", "dDocType")$>
    <$if not (newType like oldType) and not (userHasRole("admin"))$>
    <$abortToErrorPage("Only administrators can change dDocType.")$>
    <$endif$>
    
  22. Click OK.

  23. Click OK.

  24. Click OK.

    The rule is added to the list of Rules.