Administering Portals

This chapter provides an overview of portal administration and discusses how to:

• Administer portal definitions.

• Administer folders.

• Administer content references.

• Manage folders and content references.

• Manage general portal settings.

• Manage portal objects.

• Review menu item information.

• Build registry search indexes.

Understanding Portal Administration

Every component delivered with PeopleSoft applications is pre-registered within the portal registry as a content reference. Common administrative tasks include adding, deleting, and renaming portal definitions. If you have portal administrator access, you can use the administration pages to manage the registry, including folders, content references, and security.

Additionally, to provide programmatic access to the portal registry, PeopleSoft delivers a portal registry API. This API provides the same kind of registry management capability as the administration pages and is fully described in the PeopleCode documentation. You can also manage the registry with the registration wizard.

You use the administration pages to:

• Manage the structure and content of a portal, including folders and external content references.

• Manage general portal settings, including the portal description and node templates.

• Populate a portal registry with custom menus by importing menu definitions.

• Generate a Verity search index or collection for use with your portal, based on the content of the portal registry.

• Add, edit, and delete local and remote portal definitions.

The following diagram shows the organizational structure of the portal administration pages and folder definitions. Note the location of the special Portal Objects folder. This folder contains folders and content references for all templates and pagelets associated with a given portal.

Portal administration pages

Note. To access the portal administration pages, you must have the appropriate permissions in PeopleSoft Security.

See Also

Adding and Configuring Nodes

Common Elements used in This Chapter

Administering Portal Definitions

This section discusses how to:

• Define portals.

• Add and edit portal definitions.

• Change default portals.

Common Elements Used in This Section

Pages Used to Administer Portal Definitions

Defining Portals

Access the Portal Definitions page.

You can have multiple portals on a database or create one portal on multiple databases. You can define portals from other databases and associate them with a node. This supports transfers between portals and redirected requests for a portal not supported by the local web server.

See Also

Managing General Portal Settings

Adding and Editing Portal Definitions

Access the Portal Definitions - Add Portal page.

Note. The Edit Portal page contains the same fields as the Add Portal page.

Folder Navigation

By enabling folder navigation, you change the default behavior of all menu (folder) names in the navigation pagelet. Instead of expanding a menu to reveal its child entries, clicking the menu name opens a specified content reference in the target content region and expands the menu to show the navigation path to that content reference.

Important! You must also enable site-wide folder navigation in the portal's general settings for this feature to work. Doing so enables folder navigation for all folders. Enabling folder navigation is selected by default.

See Managing General Portal Settings.

Changing Default Portals

There are two ways to change the default portal:

• Change the default portal in the portal definition.

• Insert the new default portal name into the URL.

Changing the Default Portal in the Portal Definition

To change the default portal:

1. In the current portal, select PeopleTools, Portal, Portal Definition.

2. Select the Default check box for the portal that you want to open.

3. Sign out.

4. Shut down and restart the portal's web server.

5. Sign in.

   When you sign in, the new default portal is invoked.

Changing the Default Portal by Inserting the New Portal Name in the URL

You can also change the default portal by changing the URL. To change the URL, insert the new portal name instead of the existing portal name. For example, to change to the supplier portal from the employee portal, make the following substitution.

URL before the change:
http://localhost/psp/ps/EMPLOYEE/QE_LOCAL/c/UTILITIES.PORTAL_DEFINITIONS.GBL

URL after the change:
http://localhost/psp/ps/SUPPLIER/QE_LOCAL/c/UTILITIES.PORTAL_DEFINITIONS.GBL

Administering Folders

This section discusses how to:

• Define folders.

• Delete folders.

• Set folder security.

Pages Used to Administer Folders

Defining Folders

Access the Folder Administration page.

Name	Enter a name for the folder. Note. The name can consist of letters, digits, and underscores ( _ ). It cannot contain any spaces and cannot begin with a digit.
Label	Enter the text to appear as the link for this folder.
Copy object	Click this button to access the Copy Object to a Different Portal Registry page, which enables you to copy an existing folder to a different portal registry. This button appears only when you're editing a folder.
Select New Parent Folder	Click to copy the folder to a new location within the current portal registry. This button appears only when you're editing a folder.
Long Description	Enter text to appear when the cursor rests over the link for this folder. If you leave this field blank, the label appears.
Product	(Optional) Portal-aware applications can use this field for group processing. All PeopleTools objects have the product name PT.
Sequence number	Enter a sequence number to define where this folder appears in its parent folder, and therefore where its associated menu entry appears within its parent menu. If you leave the sequence number blank, the folder is added to the top of the list of folders and is displayed in alphabetical order. You can change the sequence only one item at a time, and each time you do so, you must save your changes to see the result.
Valid from date and Valid to date	Enter a valid from date. The valid to date is optional and is blank by default. These dates can be used for application-specific processing by portal-aware applications and are used by the portal navigation to determine visibility.
Object Owner ID	Select an ID. This enables you to change the ownership of the folder definition.
Hide From Portal Navigation	Select to make this folder invisible to users.

Folder Navigation

Enable or disable folder navigation.

See Adding and Editing Portal Definitions.

Folder Attributes

(Optional) Specify a name, a label, and an attribute value for each attribute. These values can be used by portal-aware applications for application-specific processing. Select the Translate check box to make an attribute's label and attribute value translatable.

See Also

Using the Menu Pagelet

Deleting Folders

To delete a folder:

1. Select PeopleTools, Portal, Structure and Content.

2. Navigate to the folder that you want by drilling down through the folder names.

3. Click the Delete button next to the folder that you want to delete.

   All child folders and child content references are deleted when you delete the selected folder. Make sure that no critical dependencies exist for these objects before deleting their parent folder.

Setting Folder Security

Access the Folder Security page.

Public	Select to make the folder available to all users. When this is selected, all other fields except Label are hidden.
Author Access	Select to indicate that you (the currently signed-in user and the author of the folder) can access the folder in the future, regardless of how other permissions are set.

Security Authorizations

You can base non-inherited folder security on roles or permission lists. You can specify any combination of roles and permission lists to provide folder security.

Inherited Security Authorizations

Displays authorizations that have been inherited from parent folders. The fields in this grid have the same purpose as the corresponding fields in the Security Authorizations grid. You can change inherited authorizations by modifying the parent folders' authorizations and cascade settings.

See Also

Setting Up Permission Lists

Setting Up Roles

Administering Content References

This section discusses how to:

• Define content references.

• Create related links.

• Set content reference security.

• Review content reference security.

• Test content references.

• Delete content references.

• Define content reference links.

• Set content reference link security.

Pages Used to Administer Content References

Defining Content References

Access the Content Ref Administration page.

Note. Many of the fields described in this section only display when certain values are specified.

Many of these fields are similar to fields for administering folders on the Folder Administration page.

When you save a content reference that points to a PeopleSoft component or script on the default local node, the security settings for the content reference are automatically inherited from the menu or script security settings. Any permission lists or roles that you entered on the Content Reference Security page before saving the content reference are deleted and replaced by those of the component or script. These new security settings are also propagated up the folder hierarchy. This ensures that the content reference is visible and all folders are viewable, enabling users to navigate to the component.

Warning! Do not add internal PeopleSoft content references using the administration pages. Use the registration wizard instead, so that information is consistent between PeopleSoft Application Designer and the portal. Any changes made to the menu definition in PeopleSoft Application Designer and not made to the portal content reference definition break the content reference. The portal navigation system uses the portal registry, not the internal location of menu definitions in PeopleSoft Application Designer.

See Using the Registration Wizard.

URL Information

The fields that appear in this group box are based upon the selection you make in the URL Type field.

Pagelet Attributes

The Pagelet Attributes group box enables you to manage the pagelet's behavior and appearance.

See Managing Pagelet Attributes.

Content Reference Attributes

Content reference attributes provide a framework to specify and store free-form information about a content reference. For example, you can use content reference attributes to specify and store keywords, help information, and related links for content references.

In addition, portal-aware applications can use content reference attribute information for application-specific processing. Portal-aware applications are those that:

• Know about the portal registry and API.

• Know how to get information from a content reference.

• Have the code to look at a content reference and do something meaningful with the information.

Links

This grid appears only if content reference links exist that connect to this content reference. Click Link Definition to view the definition of each listed content reference link.

Available Content Reference Attributes

This table describes the content reference attributes that are recognized by PeopleSoft portal technology:

Content Reference Type Parameters

This table summarizes the valid combinations of usage type, storage type, and URL type or key HTML content supported for content references:

See Also

Defining Folders

Understanding Portal Templates

Managing General Portal Settings

Configuring Pagelet Time-outs

Using Predefined Homepage HTML Objects

Administering Server-Based Caching

Overriding Page Encoding

Creating Related Links

You can create related links for a portal page using the RELLINK content reference attribute. You can create related links to external sites, to internal sites, and to other portal pages.

Note. Related links are implemented with your choice of template on the content reference. Using the PeopleTools Related Links template displays the related links for the content reference, but not the portal menu navigation.

To create related links:

1. Define the RELLINK content reference attribute.

2. Create related links groups.

3. Create related links for each group.

4. Test the related links.

The following diagram shows an example of the related link template results when using the RELLINK attribute on a given content reference:

The items shown in the diagram are described in this table:

Defining the RELLINK Content Reference Attribute

To define a related link content reference attribute:

1. Access the Content Ref Administration page for a content reference.

2. From the Template Name field, select RELATEDLINKS_TEMPLATE.

3. In the Name field of the Content Reference Attributes region, enter RELLINK.

   After you set this value and move out of the field, the Attribute Information link changes to Edit Related Links.

4. Verify that the Translate check box is selected.

5. Enter a label for the related links attribute.

Note. You do not need to enter any information in the Attribute Value field. After you create the related link group and the related links, the system populates this field with all defined attributes as a string.

Creating Related Link Groups

Access the Related Links Group (PORTAL_RLNK_ADM) page.

To create a related link group:

1. In the Related Link Groups Label field, enter a name.

   This name is the heading under which you place related links.

2. To create additional related link groups, click Add and repeat step 1.

Creating Related Links

To create a link:

1. In the Related Links region on the Related Links Group (PORTAL_RLNK_ADM) page, enter a name in the Related Link URL Label field.

   This name appears as a link under the group name.

2. If you're linking to an internal site, select a node name from the list.

   If you're linking to an external site, leave this field blank.

3. In the Related Link URL field, enter URL information for the link.

   If the link is to an internal site, enter the URL or URI. The URL or URI can be to an internal site, to a portal, and so on. If you specified a value for the Portal URI Text field on the node definition, you can enter a specific document name as the target. The name is appended to the URI text for a full URL.

   If the link is to an external site, enter the URL.

4. To define additional links for the group, click Add and repeat steps 2 through 3.

5. Click OK to save the entry and return to the Content Ref Administration page.

   The Attribute Value field is populated with an XML-type formatted string. This string contains all the related link data and is stored in the PORTAL_ATTR_VAL field of the PSPRSMATTRVAL record for the content reference specified in the PORTAL_OBJNAME field. Following is an example of a generated XML-type formatted string:

   <GRPLBL>Worklist Pages<URLLBL>Worklist Details</URLLBL><CP>Portal</CP><URL>ICType=Panel&Menu=WORKLIST&Market=GBL&PanelGroupName=WORKLIST_DETAILS</URL><URLLBL>Worklist
   Monitor</URLLBL><CP>Portal</CP><URL>ICType=Panel&Menu=WORKFLOW_ADMINISTRATOR&Market=GBL&PanelGroupName=WF_MONITOR_01</URL></GRPLBL><GRPLBL>Tasks<URLLBL>Task
   List Summary</URLLBL><CP>Portal</CP><URL>ICType=Panel&Menu=PORTAL_COMPONENTS&Market=GBL&PanelGroupName=EO_PE_TASK_LIST</URL></GRPLBL>

Testing Related Links

You should test related links to view how the page appears to users, ensure that the labels are correct, and verify that the links function properly. To test related links, click Test Content Reference on the Content Ref Administration page just above the URL Information region.

Note the following:

• If the portal cache is enabled on the web server, the related link template does not appear for a content reference page accessed from the menu until the cache expires.

• Related link URLs are only displayed when a user has security access to the URLs.

  To grant security access to a related link URL, register the related link URL as a separate content reference and associate permission lists with it.

  If the related link is not separately registered, then it is treated as having public access.

  If a related link group has no URLs underneath it to which the user has security access, the related link group is hidden. If the user does not have access to any of the related links associated with the target page, then the related links section of the template is hidden.

If the target page does not display any related links, ensure the following:

• The application and portal databases are registered as content providers.

  Also check for data-entry errors.

• The templates are registered in PeopleSoft Application Designer with the correct names.

  If the templates are registered, check for data-entry errors.

• The correct related link template is specified for the target page.

  Also ensure that the value of the PORTAL_TEMPL_NAME field in the PSPRSMDEFN record displays a correct related link template

• The RELLINK string was saved on the target page in the content registry.

  Check if an XML string appears in the Attribute Value field on the Content Ref Administration page. If not, delete and reenter the RELLINK attribute for all the related link information.

• You assigned security in the registry to the user for the content references listed as related link URLs.

  If not, assign security using the Content Reference Security page for registered related link URLs.

Setting Content Reference Security

Access the Content Reference Security page.

This page is similar to the Folder Security page, except that when you define a portal content reference for which the URL type is PeopleSoft Component, Worklist, or PeopleSoft Script, the content reference security is always inherited from the security settings of the referenced component or script. All fields except Public and Author Access are read-only.

However, when you define a content reference of any other type, you can specify the type of security to apply, just as you can with a portal folder. You can base non-inherited object security on any combination of permission lists and roles.

Note. If you copy, move, or add a content reference to a folder, the content reference's security settings are propagated up the folder hierarchy. This ensures that the content reference is visible and all folders are viewable, and enables users to navigate to the content reference. If you remove the content reference from that folder, the security settings that were applied when it was added to the folder are also removed from the folder hierarchy, without disturbing any settings still required for other content references remaining in that folder.

Note. Content reference links do not inherit cascaded security from folders.

See Also

Setting Folder Security

Using the Registration Wizard

Setting Up Permission Lists

Setting Up Roles

Reviewing Content Reference Security

You can use automated queries to discover the content references to which a given user, permission list, or role has access. Each query provides a different degree of detail about the properties of the content references.

Content Reference Security by User

Access the User ID Queries page.

This page contains several general purpose security queries, along with the following links to content reference access queries for the selected user, which are described on the page:

• User ID's Content Reference Access.

• User ID's Content Reference (includes Portal) Access.

• User ID's Content Reference (includes Menu, Component and Market) Access.

• User ID's Content Reference (includes Portal, Menu, Component and Market) Access.

When you click one of the query links, a page appears in a new window, containing a grid with the information described for each content reference.

Content Reference Security by Permission List

Access the Permission List Queries page.

This page is similar to the User ID Queries page, with equivalent links to content reference access queries for the selected permission list, as follows:

• Permission List's Content Reference Access.

• Permission List's Content Reference (includes Portal) Access.

• Permission List's Content Reference (includes Menu, Component and Market) Access.

• Permission List's Content Reference (includes Portal, Menu, Component and Market) Access.

When you click one of the query links, a page appears in a new window, containing a grid with the information described for each content reference.

Content Reference Security by Role

Access the Role Queries page.

This page is similar to the User ID Queries page, with equivalent links to content reference access queries for the selected role, as follows:

• Role's Content Reference Access.

• Role's Content Reference (includes Portal) Access.

• Role's Content Reference (includes Menu, Component and Market) Access.

• Role's Content Reference (includes Portal, Menu, Component and Market) Access.

When you click one of the query links, a page appears in a new window, containing a grid with the information described for each content reference.

Testing Content References

After creating or modifying a content reference and setting up permissions, test the content reference by clicking Home and navigating to it, or by clicking Test Content Reference on the Content Ref Administration page.

Note. The Test Content Reference link appears only for content references that are of the Target usage type.

Deleting Content References

You delete a content reference or a content reference link from the folder where it's located in the Structure and Content hierarchy. Select PeopleTools, Portal, Structure and Content, Portal Objects, then click the Delete button for the content reference that you want to delete.

Warning! Do not delete content references that are delivered with PeopleTools. These default content references have special significance to your portal. Changing them could make your portal unusable.

When you delete a content reference or a content reference link, all content reference links that connect to it are also deleted. This behavior propagates back through any content reference link chain.

Defining Content Reference Links

Access the Content Reference Link Administration page.

PeopleSoft portals store content references based on their URLs, so you can't register two different content references that specify the same URL. Content reference links overcome this limitation by enabling you to define more than one menu item that invokes a given URL. You define a content reference link like any other content reference, but instead of specifying a URL, you specify an existing content reference as its destination. At runtime, clicking the content reference link entry on the portal menu connects to the destination content reference, which invokes its URL.

Note. To the user, a content reference link looks and works the same as a content reference on the portal menu.

A content reference link can connect to:

• A content reference of usage type Target.

• Another content reference link.

You can define a content reference link in the same locations that you can define a content reference of usage type Target. Multiple content reference links can connect to a single destination content reference.

By connecting one content reference link to another content reference link, you can create a chain of redirection, which always ends in a content reference of usage type Target. You don’t need to know what the ultimate destination is when you define your new content reference link, and you can duplicate the property settings of the content reference link to which it connects, rather than those of the ultimate destination. However, it is recommended that you limit your use of chains of content reference links as they impose processing overhead on your portal when selected.

Warning! If you delete a destination content reference or content reference link, all content reference links that connect to it are also deleted. This behavior propagates back through any content reference link chain.

When you define a content reference link, it initially inherits its properties and security settings from the destination that you specify. You can override every property except the destination's URL, usage type, storage type, and security settings. The inherited security settings propagate upward through the folder hierarchy from the content reference link.

Target Information

Link Information

If you leave the following fields blank, their values are inherited from the destination content reference:

• Label.

• Long Description.

• Product.

• Sequence number.

• Object owner identifier.

• No Template.

• Template Name.

• Valid from date.

• Valid to date.

Content Reference Link Attributes

Content reference link attributes have the same page fields as content reference attributes.

You can define content reference link attributes directly here, or you can copy an attribute from the destination content reference using the Content Reference Attributes grid, and modify it to suit your purposes.

At runtime, the content reference link attributes defined here are combined with the content reference attributes defined at the link destination, and applied together.

Important! If a content reference link attribute defined here has the same name as a content reference attribute defined at the link destination, but a different attribute value, the value defined here takes precedence and is applied at runtime.

Content reference link attributes are independent and separate from the content reference attributes at the link destination. Modifying one has no effect on the other.

Content Reference Attributes

If the destination content reference has defined content reference attributes, they're displayed in this grid. You can copy them from the grid to the Content Reference Link Attributes group box, using the following page elements:

Setting Content Reference Link Security

Access the Content Reference Link Security page.

This page is almost identical to the Content Reference Security page.

See Also

Setting Content Reference Security

Managing Folders and Content References

This section discusses how to:

• Copy folders and content references.

• Move folders and content references.

• Synchronize portal object security.

• Register components in multiple portals.

• Register components multiple times.

Pages Used to Manage Folders and Content References

Copying Folders and Content References

Access the Copy Object to a Different Portal Registry page.

To copy an object:

1. Navigate to the portal registry to which you want to copy the object.

   Click the portal name to copy the object to root level. To expand the folders and navigate further into the registry structure, click the folder icon (not the folder name).

   Important! Clicking the folder name starts the copying process.

2. (Optional) If you are copying a folder, the Recurse subfolders? check box appears. Select this check box to copy the folder and all the subfolders and content references within it.

3. Click the folder name to copy the object into that folder.

4. Click the Yes - Copy button to proceed.

Warning! If you attempt to copy an object to a location that already contains an object of the same name and type, the newly copied object replaces the existing object. For example, if you copy a folder and subfolders to another portal where a subfolder by that name already exists, the existing subfolder is deleted and replaced by the subfolder from the source portal. There is no warning message.

Moving Folders and Content References

Access the Select New Parent Folder page.

The current parent folder is shown in bold type, and the folder tree is expanded just enough to show the location of the current parent folder. All other folders are shown collapsed. You can expand the tree to show content references, which are displayed as tree leaves and appear in normal text.

To move a folder or content reference to a new parent folder:

1. Navigate to the new parent folder by clicking the appropriate folder icons with plus signs.

   Note. When navigating, do not click the folder name, unless it’s the name of the new parent folder that you’d like to select. Once you click a folder name, as opposed to the icon, the folder name that you selected becomes the new parent folder.

2. Select the new parent folder by clicking the folder name.

3. Click Save.

Note. When you move a content reference that points to a component or script at the default local node, its security settings are cascaded up to its new parents all the way up to the root folder. In addition, when you move a folder, its security settings (not including security inherited from a subordinate object) are cascaded up to its new parent, all the way up to the root folder. This ensures that the folder or content reference is accessible in its new location.

Synchronizing Portal Object Security

Access the Portal Security Synchronization page.

The hierarchical relationships and dependencies between objects in the portal registry determine what security settings each object must have. The portal won't work correctly if these security relationships aren't maintained. Here are some examples of these relationships:

• A folder that is not public or hidden must have at least the level of access that its immediate child objects (folders, content references, and content reference links) have.

• A content reference link must have exactly the same level of access as the object (content reference or content reference link) to which it links.

• A content reference that represents a PeopleSoft component or iScript must have exactly the same level of access as the object that it represents.

Portal object security settings can become unsynchronized when you move portal objects from one database to another using the Project Copy feature in PeopleSoft Application Designer. When you merge projects this way, if the projects contain any portal objects with identical names, the security settings of the portal objects in the last project copied overwrite the security settings of portal objects copied earlier. Also, when a copied portal object doesn't overwrite an existing object, it changes the structure of the resulting portal registry hierarchy.

Use the Portal Security Synchronization page to reinstate the correct security relationships between objects in the portal registry after you copy a project that contains portal objects.

This page enables you to run the Application Engine program PORTAL_CSS from the standard menu navigation. You can use this feature on local portals only, not on portals on remote databases. In addition, from any local portal, you can run this program against another local portal.

To synchronize portal object security, specify a local portal in the Portal Name field and click Run. The portal objects are synchronized as follows:

1. The security settings of each content reference are compared to the component or iScript that it represents, and updated to match.

2. The security settings of each content reference link are compared to the content reference or content reference link to which it connects, and updated to match.

3. The security settings of each content reference and content reference link are propagated to its parent folder, in addition to the parent folder's existing settings.

   None of the parent folder's existing security access is reduced.

   Note. The settings aren't propagated if the parent folder is public or hidden.

4. The security settings of each folder are propagated to its parent folder, in addition to the parent folder's existing settings.

   None of the parent folder's existing security access is reduced.

   Note. The settings aren't propagated if the parent folder is public or hidden.

The following warning messages may appear when security synchronization cannot occur:

• No permissions in PSAUTHITEM for object %1

• Cref %1 points to Menu: %2, Component: %3 which doesn't exist.

  Note. When this message appears you need to delete the invalid cref.

It is the responsibility of the security administrator and portal administrator to determine why an object has no security or why an object does not exist.

Delete Invalid Security Option

When you move portal objects from one database to another, roles and permission lists assigned to folders and content references on the source database may not exist on the target database and therefore become invalid. Select the Delete Invalid Security check box on the Portal Security Sychronization page to remove non-existing roles and permission lists from folders and content references.

Note. When the Delete Invalid Security option is selected, the PORTAL_CSS process runs more slowly as it checks every role and permission list on every portal registry structure. When a non-existing role or permission list is found on the portal registry structure, it is removed from that portal registry structure.

Registering Components in Multiple Portals

After you've used the registration wizard to register a new component on a portal, you may need to register the component on other portals. There are two ways to register components on multiple portals:

• Use the registration wizard again.

  Select the second option: Add this component to a portal registry. Then reenter the content reference label, long description, and sequence number (if not 1) to match the other portal’s entry.

• Copy the component to other portals.

  When you have copied your component to another portal, open that portal to verify that it was copied as anticipated.

See Copying Folders and Content References.

See Also

Changing Default Portals

Registering Components Multiple Times

The portal registry does not allow a URL to be registered more than once. When defining a content reference, the component name is part of the URL. If you must register the same component URL in more than one location, add a unique character to the parameter field. (Be sure you really must register a URL twice, because this creates upgrade and maintenance concerns.) See the following example, where the additional numeric character 1 is added to the Additional Parameter field:

See Also

Registering Components in Multiple Portals

Managing General Portal Settings

This section discusses how to manage general portal settings.

Page Used to Manage General Portal Settings

Managing General Portal Settings

Access the General Settings page.

Use this page to manage the settings for the portal that you're signed in to. To modify other portals, use the Portal Definitions page.

Note. You must sign out of the portal and sign back in before your changes take effect.

See Administering Portal Definitions.

Folder Navigation

Enable or disable folder navigation.

Enabling folder navigation for the portal enables folder navigation for all folders. Enabling folder navigation is selected by default. However, you can subsequently disable this feature for individual folders.

If you don't specify a folder navigation object for an individual folder, the one that you specify for the portal is used instead. If you do specify a folder navigation object for a folder, that folder is used instead of the one that you specified for the portal.

Note. The folder navigation object name for the base navigation page is EOPP_SCFNAV_BASEPAGE_SCR.

See Adding and Editing Portal Definitions.

Portal Search Options

Use this section of the page to specify search options in the menu or the header.

Enter the names of the menu, component, and market for the Search Results page.

Favorites Options

Select the checkbox to display the My Favorites folder.

Menu Text Options

Header Frame Options

This group box sets the number of header frame rows if you are using the Tools default template. . The value added for this field determines the size of the header frame. The default for PeopleTools is 65 and the default for Enterprise Portal is 100.

Node Templates

Configure node-specific template information.

See Also

Using the Menu Pagelet

Managing Portal Objects

The Portal Objects folder is of special significance to the portal. This section discusses how to:

• View Portal Objects folder settings.

• Manage templates.

• Add and edit templates.

• Delete templates.

Pages Used to Manage Portal Objects

Viewing Portal Objects Folder Settings

Access the Structure and Content - Portal Objects page.

Managing Templates

Templates are stored in the HTML catalog and are edited through the portal administration pages. For the portal to process templates properly, they must be referenced in the Templates folder within the Portal Objects folder. Storing templates in the HTML catalog enables them to be upgraded like other objects.

Templates are stored in the HTML catalog according to the following naming convention. Template names always begin with the literal PR_. Here's an example name: PR_PORTALNAME_CONTENT REFERENCE ID

The following example shows a sample template:

Templates can be larger than the maximum size permitted by the HTML catalog. Such templates are automatically divided into several files in the HTML catalog. In this case, a letter is appended to each HTML object that makes up the template, as follows:

PR_EMPLOYEE_123456789_A

PR_EMPLOYEE_123456789_B

See Also

Working with Portal Templates

Adding and Editing Templates

Access the Content Ref Administration page.

The fields for adding a dynamic template are the same for as any content reference, except for additional iScript parameter fields. These fields are enabled only if the storage type is set to Remote by URL.

If the URL Type field is set to PeopleSoft Script, the iScript Parameters region appears. Select the record name, PeopleCode event name, field name, and PeopleCode function name that describe the iScript to use for the content reference.

To add a new template, click Add Content Reference. in the Content References region at the bottom of the Content Ref Administration page.

To edit an existing template, click the Edit link next to the template that you want to edit in the Content References region at the bottom of the Content Ref Administration page.

See Also

Defining Folders

Defining Content References

Deleting Templates

You delete templates just as you delete folders and content references.

Note. Do not delete the PORTAL_DEFAULT template. This template has special significance to your portal, and must always be available. Deleting this template could make your portal inoperative. Do not delete a template unless you are fully aware of how it's used within the portal.

See Deleting Content References.

Reviewing Menu Item Information

This section discusses how to:

• View menu item details.

• View menu folder structure information.

• View menu security details.

Common Elements Used in This Section

Pages Used to Review Menu Item Information

Viewing Menu Item Details

Access the Menu Item Details page.

Use this page to review the portal registry information for a menu item. The details that appear include the exact users and the roles and permission lists that allow access to a given menu item.

Note. The Accessible Permissions, Accessible Roles, and Accessible Users scroll areas are only populated if the access type is set to permission list.

See Defining Content References.

Accessible Permissions

Displays the permission name and description for all permission lists that have access to this menu item.

Note. If the component or iScript is using a local node with no extra parameters, the permission lists are automatically populated based on the menu object component security.

Accessible Roles

Displays the role name and description for all roles that have access to this menu item.

Accessible Users

Displays the user ID and description for all users that have access to this menu item.

Viewing Menu Folder Structure Information

Access the Menu Folder Structure page.

Use this page to view a list of content references for a selected portal registry folder. You see the contents of one or several menu folders.

Objects Tab

Select the Objects tab.

Details Tab

Select the Details tab.

User ID

If the Auth Access check box is selected, displays the author's user ID.

Viewing Menu Security Details

Access the Menu Security page.

Use this page to view a list of folders or content references to which a user ID, role, or permission list has access.

Note. The Seq Nbr (sequence number) column is hidden in this illustration, and because of the large number of objects, not all are shown.

Object Security

Select the level of object security for the menu information that you want to see.

Folder Visibility

Select the folder level of visibility for the menu information that you want to see.

Objects Tab

Select the Objects tab.

See Viewing Menu Folder Structure Information.

Details Tab

Select the Details tab.

See Viewing Menu Folder Structure Information.

Permission Lists

If either the Role object security option or the Show Top Level Only folder visibility option is selected, then this scroll area appears, displaying the permission lists that are associated with each menu item.

Building Registry Search Indexes

This section discusses how to

• Associate keywords to content references.

• Build search indexes for portal applications.

Page Used to Build Registry Search Indexes

Associating Keywords to Content References

Access the Content Ref Administration page.

The search index derives keywords from the content reference labels and long descriptions. Additional keywords can be assigned to a content reference by adding portal KEYWORD attributes. This is very useful if there are synonym-type keywords that are not mentioned in the title or description; for example, P.O. versus Purchase Order.

Note. Attribute values must be separated with a comma and a space.

Building Search Indexes For Portal Applications

You can build a search index from the portal administration pages and schedule the build process using PeopleSoft Process Scheduler. Each time that you build the search index, the index is entirely rebuilt, and any previous entries are overwritten.

Note. Only content references can be indexed.

The process for building a search index for a portal application is fairly easy, because data in the portal registry is already in a known format and this data is used to build the search index. When you build a search index from the portal administration pages, an Application Engine program calls a C++ program, PORTAL_INDEX, which reads from the portal registry. The C++ program then generates the bulk insert files to create the search index. The following illustration represents this process:

Building a search index process

To build a search index:

1. Access the Build Search Index page.

2. Select or add a run control ID.

   You may use any run control ID; however, you may want to use a portal name to associate the run control ID with the registry for which you are building the search index.

3. Select the All Installed Languages box to build the index for all installed languages.

4. Select the language code for which you want to build the search index.

   The default language code is the base language.

5. Click Run to launch the build process.

   PeopleSoft Process Scheduler initiates an Application Engine program named PORTAL_INDEX. Click the Process Monitor link to view the status of the index build. Click Report Monitor to review output.

See Also

Configuring Search and Building Search Indexes