Skip to Main Content
Return to Navigation

Defining Permissions

This section discusses how to:

Setting General Permissions

Access the Permission Lists - General page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the General tab).

Image: Permission Lists - General page

This example illustrates the fields and controls on the Permission Lists - General page. You can find definitions for the fields and controls later on this page.

Permission Lists - General page
Navigator Homepage

Select a graphic representation of a business process that is displayed by PeopleSoft Navigator. For each security profile definition, you can specify a map to be displayed on startup.

If this is the user profile's PeopleSoft Navigator homepage permission list, the system is passed this value at runtime.

Can Start Application Server?

Select to enable user profiles with this permission list to start PeopleSoft application servers.

Note: This setting also applies to starting PeopleSoft Process Scheduler servers.

Typically, you will create a user profile that is dedicated to starting application servers. When you define an application server domain, one of the parameters you specify in PSADMIN is the PeopleSoft user ID (and password) for that profile, which must be associated with at least one permission list that has this option enabled. The user ID and password are stored in the Startup section of the PSAPPSRV.CFG file, which Oracle Tuxedo reads when the application server is started.

In many installations, an application server starts with an automated process. A user profile with this property enabled should not be used by an actual user who signs in to the application server and starts it by submitting the appropriate commands.

Note: Password controls do not apply when a password is used for two-tier activities like starting application servers. They apply only when the password is used to sign in over three-tier connections.

Important! For a given user profile, the password controls that you set for account lockout (maximum logon attempts) and age (expiration) apply to three-tier and web sign in only; they do not apply if the user profile is used for two-tier activities like starting an application server or process scheduler.

However, make sure that you do not use the same user profile for both types of activities. When you use it for both three-tier and web sign in, the profile becomes subject to the account lockout and age controls, which prevents it from completing the two-tier activities.

Allow Password to be Emailed?

Select to enable users to receive forgotten passwords through email. At some sites, the security administrator may not want passwords appearing unencrypted in any email. You implement this feature by permission list. None can use it, some can use it, or all can use it, depending upon your implementation. Users who do not have the proper authority receive an error message if they attempt to have a new password emailed to them.

Never Time-Out and Specific Time-out (minutes)

Select the number of minutes of inactivity allowed at a terminal before the system automatically signs the user out of the PeopleSoft online system. Inactivity means no mouse clicks, keystrokes, import, file print, or SQL activity. The default time-out minutes setting is Never Time-out.

Note: Time-out limits are also controlled at the web server and application server levels.

If you select Never Time-out, an inactive user is never automatically signed out. Otherwise, select Specific Time-out (minutes) and enter the appropriate value in minutes. A custom time-out interval:

  • Must be a positive integer.

  • Cannot contain edit characters, such as commas or a $.

  • Must be a SMALLINT in the valid range allowed for this field (0-32767).

Entering a value of zero (0) is equivalent to selecting Never Time-out.

To comply with the Americans with Disabilities Act (ADA), you might set up most permission lists to time out in 20 minutes, but create a special ADA permission list for which timeout occurs after 60 minutes.

Note: Because timeout limits are also controlled at the web server level, you will need to change the web server timeout values also.

Setting Page Permissions

Access the Permission Lists - Pages page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Pages tab).

Image: Permission Lists - Pages page

This example illustrates the fields and controls on the Permission Lists - Pages page.

Permission Lists - Pages page

This table describes the fields on the Pages page.

Mobile Page Permissions

Click to grant access to mobile application pages.

Important! PeopleSoft Mobile Agent is a deprecated product. These features exist for backward compatibility only.

Menu Name

Displays all menu names in the database. Add new rows to add more menu names. The name reflects the definition name in PeopleSoft Application Designer.

Menu Label

Displays the menu label associated with the PeopleSoft Application Designer menu name.

Edit Components

Click to grant access to specific pages.

Page permissions refer to the pages to which a user has access. Pages are contained within components, which are ultimately contained within a menu name. To grant access to a particular page, determine the component it is in and the menu name the component falls under. This enables you to drill down to the appropriate page.

When you click the Edit Components link, the Component Permissions page appears:

Image: Component Permissions page

This example illustrates the fields and controls on the Component Permissions page.

Component Permissions page

This table describes the fields on the Component Permissions page:

Authorized

This field indicates whether at least one page in the component is authorized for current the permission list. This field is display-only.

Component Name

This field indicates the component where the pages reside. This field is display-only.

Item Label

This field indicates the item label on the menu definition where the component resides. This field is display-only.

Edit Pages

Click this link to grant access to individual pages and the appropriate actions.

View Content References for this Component

Click this link to access the content reference.

When you click the Edit Components link, the Page Permissions page appears:

Image: Page Permissions page

This example illustrates the fields and controls on the Page Permissions page. You can find definitions for the fields and controls later on this page.

Page Permissions page

This table describes the fields on the Page Permissions page:

Panel Item Name

This is the name of the panel item as entered in the component in Application Designer. This field is display-only.

Authorized?

Select this check box to authorize user access to the page.

Display Only

Select this check box to authorize view only user access to the page. No fields are active when this check box is selected.

Actions

Select from the following check boxes:

Add: The user can create new high-level key information through the search page.

Update/Display: The user can view the current row. The user can view, insert, and update future rows.

Update/Display All: The user can view the history and current rows. The user can view, insert, and update future rows.

Correction: The user can view, insert, and update history, current, and future rows.

Note: Only actions that are selected in the component definition in Application Designer are enabled.

Note: To find the name of a menu, component, or page, you can press Ctrl+J or Ctrl+Alt+J while accessing the page with the browser (the keyboard shortcut differs depending on the browser you use), or use the Find Definition References feature in PeopleSoft Application Designer.

Granting access to PeopleTools and PeopleSoft applications requires serious consideration. For each role, carefully consider what the members of that role must access to complete their jobs and to what degree they need access. Then make the appropriate permission lists.

After you add a menu name, you grant access to its components and pages on an item-by-item basis. In PeopleSoft applications, menu items represent components. If a component consists of more than one page, then selecting the menu item opens another layer with more items—individual pages. For example, if you added the UTILITIES menu name to a permission list, you could then grant access to the Utilities, Use menu items but not to the Utilities, Process menu items. Alternatively, you could grant access to only a few of the Use menu items or make some items display only.

You grant access permission to two categories of components:

  • All PeopleSoft applications.

  • Page-driven PeopleTools.

Note: With PeopleTools programs, the process of editing menu items varies. With page-based PeopleTools, such as PeopleSoft Process Scheduler, you can grant access to menu items just as you can for PeopleSoft applications. However, the other PeopleTools programs do not allow you to grant item-by-item access; you can either access all the menus and menu items or you cannot. PeopleSoft Application Designer is an exception; you can restrict access to it at the definition level.

Granting Access to Components and Pages

The following procedure describes how to set access permissions to your PeopleSoft applications and your page-driven PeopleTools. You begin at the component level and drill down to the page level, making the appropriate selections as you go.

Note: The same procedure applies to both PeopleSoft applications and page-driven PeopleTools.

To add access to PeopleSoft components and pages:

  1. Locate the menu name of the component to which you want to add access.

  2. Click Edit Components.

    The Components page appears.

  3. Locate the component to which you want to grant access.

    By default, when adding a new permission list, no components are authorized.

  4. Click the Edit Pages button associated with each component to which you want to grant access.

    The Page Permissions page appears. You specify the actions that a user can complete on this page. You can select from these options for each page that appears in the Page column:

    • Authorized?

      Select to enable a user to access the page. Decide the degree to which a user is authorized on a page by selecting Display Only or one or more of the available options in the Actions group.

    • Display Only.

      Select to enable the user to view the information provided by the page but not to alter any data.

    • Actions.

      Specify how users can alter information on a page, such as Add, Update/Display, and Correction. The available options depend upon the options selected when the page was initially developed in PeopleSoft Application Designer.

      To grant access to all pages and all actions for each page, click Select All.

  5. When you have finished making the appropriate selections, click OK on the Page Permissions page, and then again on the Component Permissions page.

    Repeat each step for each menu name.

Note: After you delete access to a component or iScript, you must clear the browser cache or wait for 20 minutes (default time) for the deletion to appear in the menu.

Granting Access to Mobile Pages

To add access to mobile pages:

Important! PeopleSoft Mobile Agent is a deprecated product. These features exist for backward compatibility only.

  1. Select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists, and select the Pages page.

  2. Click the Mobile Page Permissions link.

    The Mobile Page Permissions page appears.

  3. To add a new mobile page to the permission list, click the plus sign.

  4. For the Mobile Page Name edit box, click the search button.

  5. Search for and select the mobile page for which you need to grant access.

  6. Click OK.

  7. Save the permission list.

Setting PeopleTools Permissions

Access the Permission Lists - PeopleTools page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the PeopleTools tab).

Image: Permission Lists - PeopleTools page

This example illustrates the fields and controls on the Permission Lists - PeopleTools page.

Permission Lists - PeopleTools page

The PeopleTools Permissions section of this page applies to standalone PeopleTools applications. They are not Pure Internet Architecture-based, but are Microsoft Windows programs that were not developed using PeopleSoft Application Designer. They include:

  • PeopleSoft Application Designer.

  • PeopleSoft Data Mover.

  • PeopleSoft Definition Security.

  • PeopleSoft Query (Microsoft Windows interface, not the browser interface).

The Performance Monitor PPMI Access check box does not control access to an application; rather, it enables PeopleSoft Performance Monitor data collators to insert performance data into the database, which enables you to view the data.

To grant access to these PeopleTools features, select the check box next to the appropriate item.

With PeopleSoft Application Designer, the procedure for applying permissions is slightly more complex, because security for PeopleSoft Application Designer also controls what object definition types can be accessed and what degree of modifications can be made. The Definition Permissions, Tools Permissions, and Miscellaneous Permissions links enable you to provide more detail to PeopleSoft Application Designer access permissions.

Definition Permissions

Access the Definition Permissions page (click the Definition Permissions link on the Permission Lists - PeopleTools page).

Image: Definition Permissions page

This example illustrates the fields and controls on the Definition Permissions page.

Definition Permissions page

Grant access to the definitions that developers create using PeopleSoft Application Designer. Each type of definition that you create with PeopleSoft Application Designer appears in the definition permissions list.

Note: On this page, you add permissions to a definition type, such as Application Engine programs. You grant access to specific definitions, such as PeopleSoft Payroll Application Engine programs, using Definition Security.

Access

Select the appropriate access level. Options are:

Full Access: Definitions of the specified type can be modified. For records, this setting allows access to the Build dialog box.

No Access: No definitions of the specified type can be opened.

Read-Only: Definitions of the specified type can be opened and viewed, but not modified.

Update translates only: This level applies only to fields. This setting allows a user to modify only Translate table values.

Data admin only: This level applies only to records. It allows a user to modify only those record attributes found in the Tools, Data Administration menu (tablespaces, indexes, and record DDL).

Full Access (ALL), Read Only (ALL), and No Access (ALL)

Click to set all definition types in the list to the same access level.

Note: If change control locking is enabled, the Change Control access setting on the Tools Permissions page can override object types settings.

See Building and Maintaining Data, Understanding Definition Security.

Tools Permissions

Access the Definition Permissions page (click the Tools Permissions link on the Permission Lists - PeopleTools page).

Image: Tools Permission page

This example illustrates the fields and controls on the Tools Permission page.

Tools Permission page

In addition to securing definitions, PeopleSoft Application Designer security also involves a collection of tools, such as Build and the PeopleCode Debugger, to which developers need access.

The tools within PeopleSoft Application Designer include:

  • Build/Data Admin (select select Build, then select Project and Tools, then select Data Administration).

  • Change Control (select select Tools, then select Change Control).

  • Language Translations (select select Tools, then select Translations).

  • PeopleCode Debugger (select select Debug, then select PeopleCode Debugger Mode).

  • SQL Editor (the PeopleSoft Application Designer utility for adding SQL objects and statements to applications and application engine programs).

  • Upgrade (select select Tools, then select Upgrade).

    This tool includes Copy Project, Compare and Report, and so on.

You can set the access level individually for the Tools Permissions page options or your can use the (ALL) buttons to set across the board settings. Remember that every button affects every access level for the tools.

Build/Data Admin

Control access to the Build and Tools, Data Administration menu items. Select from:

  • No access: The user cannot access the Build menu items or the Tools, Data Administration menu items.

    Note: This setting is not available if you have set records access to No Access or to Data Admin only.

  • Build scripts only: A user with this access level can use the Build dialog box options, but the Execute SQL now and Execute and build script options are disabled. The Tools, Data Administration menu items are not available.

    Note: This setting is not available if you have set records access to No Access.

  • Build Online: With this access level, a user can use all Build dialog options, but the Tools, Data Administration menu items are not available

    Note: This setting is not available if you have set records access to No Access.

  • Full data admin access: A user with this access level can use all the Build dialog options and access the Tools, Data Administration menu items.

    Note: This setting is not available if you have set records access to No Access or Read-only.

Change Control

The change control access levels are valid only when change control is enabled. You enable change control locking using PeopleSoft Application Designer. Select from:

  • Restricted access: Restricts users from locking or unlocking objects. When change control locking is enabled, users with restricted access can only view PeopleSoft Application Designer definitions; they cannot create, modify, or delete them.

    Note: With locking enabled, this setting overrides any Full Access settings on the Object Permissions page or Miscellaneous Permissions page.

  • Developer access: The user can lock any unlocked objects and unlock any objects that he or she has locked.

  • Supervisor access: The user can unlock any locked objects, regardless of who locked them.

Language Translations

Set only two levels of access, No access and Full access. Enable this set of menu options for people involved in translating or globalizing your applications.

PeopleCode Debugger

Restrict access to the PeopleCode Debugger.

SQL Editor

Restrict developers from modifying the SQL in your applications.

Upgrade

Select No access to make all the Upgrade menu items on the Tools menu unavailable. Developers can still access the Upgrade view and modify upgrade settings in the project definition, but they cannot run any the upgrade processes.

With Read-only access, users can run compare reports against the database, but they cannot copy objects into the database.

The following table shows the relationship between the permissions that are set up within the source and the target databases, which you should consider in upgrade situations:

Source DB

Target DB

Compare?

Copy?

Export?

Import?

No access

No access

No

No

No

No

No access

Read-only access

No

No

No

No

No access

Full access

No

No

No

No

Read-only access

No access

No

No

Yes

No

Read-only access

Read-only access

Yes

No

Yes

No

Read-only access

Full access

Yes

Yes

Yes

No

Full access

No access

No

No

Yes

Yes

Full access

Read-only access

Yes

No

Yes

Yes

Full access

Full access

Yes

Yes

Yes

Yes

Miscellaneous Permissions

Access the Miscellaneous Permissions page (select the Miscellaneous Permissions link on the Permission Lists - PeopleTools page).

Image: Miscellaneous Permissions page

This example illustrates the fields and controls on the Miscellaneous Permissions page.

Miscellaneous Permissions page

Set access levels for the Miscellaneous Definitions items that appear in the PeopleSoft Application Designer Tools menu, including Access Profiles, Color, Field Format, Style, and Tool Bar.

Each of the miscellaneous definitions can be set for No access, Read-only access, or Full access. You can select the (ALL) buttons to grant the same permissions to each item.

Real-time Event Notification Permissions

Access the REN Permissions page (click the Realtime Event Notification Permissions link on the Permission Lists - PeopleTools page).

Image: REN Permissions page

This example illustrates the fields and controls on the REN Permissions page.

REN Permissions page

The REN Permissions page enables you to control REN server access. Before you grant any permissions to these actions, read the PeopleSoft MultiChannel Framework documentation.

See Configuring REN Server Security.

Data Archival

PeopleSoft Data Archive Manager is a page-driven PeopleTools application that you use to archive your application data as part of regular database maintenance. The security options in this group relate specifically to actions a system administrator would make while using PeopleSoft Data Archive Manager. The actions that a system administrator can perform within PeopleSoft Data Archive Manager are controlled by permission lists. Before you grant any permissions to these actions, read the PeopleSoft Data Archive Manager documentation.

Setting Process Permissions

Access the Permission Lists - Process page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Process tab).

Just as you define permissions for the pages a user can access, you also must specify the batch (and online) processes that users can invoke through PeopleSoft Process Scheduler. Typically, process groups are arranged by department or task. For example, the batch programs used by your payroll department probably all belong to the PAYROLL process group, or a similarly named group.

When you create a process permission list, you add the appropriate process groups so that a user belonging to a particular role can invoke the proper batch programs to complete their business transactions. You do this using the Process Group Permission page.

You use the Process Profile Permission page to specify when a user or role can modify certain PeopleSoft Process Scheduler settings.

Note: You grant Process Profile permissions directly to the user profile and Process Group permissions through permission lists.

Process Group Permissions

Access the Process Groups page (click the Process Group Permissions link on the Permission Lists - Process page).

Image: Process Group Permission page

This example illustrates the fields and controls on the Process Group Permission page.

Process Group Permission page

This page lists the process groups associated with a permission list. Process groups are collections of process definitions that you create using PeopleSoft Process Scheduler.

Typically, you group process definitions according to work groups within your organization, and typically that work group has a particular role associated with it. Regardless of how you organize process definitions, you must assign process groups to a permission list.

Users can run only the processes that belong to process groups assigned to their roles. For example, you may have a set of process definitions that relate to your Human Resources department and another set for your Manufacturing department.

Process Profile Permissions

Access the Process Profile Permission page (select the Process Profile Permissions link on the Permission Lists - Process page).

Image: Process Profile Permission page

This example illustrates the fields and controls on the Process Profile Permission page.

Process Profile Permission page
Server Destinations

You can specify output variables when running processes or jobs on a server. You have the following options:

  • File:

    If the output is going to a file, then specify the directory to which the file should be written. %%OutputDirectory%% is a meta-variable that resolves to the output directory that you specified in PSADMIN (or PSPRCS.CFG) for the Process Scheduler Server Agent.

  • Printer:

    Specify the network or local printer to which the hard-copy output should be sent. You must explicitly specify the printer; no meta-variables are available for this value.

OS/390 Job Controls

Note: This group of options applies only to DB2 UDB for z/OS.

All PeopleSoft Process Scheduler shell JCLs use meta-strings to pass data stored in the database. PeopleSoft Process Scheduler takes advantage of meta-strings to generate the JCL job cards based on the user who initiated the request. For example, Job Name and Job Account can be passed by setting the Name and Account values, respectively, on the Process Profile page. For z/OS, you have the following options:

  • Job:

    Enter %JOBNAME%.

  • Account:

    Enter %JOBACCT%.

See your relational database management system documentation and the PeopleSoft installation guides for details about JCL meta-variables and strings.

Allow Process Request

These options apply to using PeopleSoft Process Monitor. You can restrict which users are permitted to view or update a given process based on the user who launched (and owns) the process. You can specify restrictions as follows:

  • View by:

    Specify who can view processes that are launched by users who have this permission list assigned as their process profile permission list on the User Profile - General page.

    Select from the following options:

    • Owner: For a process launched by a user who has this process profile permission list assigned, only the user who launched the process can view it.

    • All: All users can view processes that are launched by a user who has this process profile permission list assigned.

    • None: No one can view processes that are launched by a user who has this process profile permission list assigned.

  • Update By:

    Specify who can update the status of processes that are launched by users who have this permission list assigned as their process profile permission list on the User Profile - General page. For example, you decide whether users can restart or cancel a request.

    Note: Updates are made using the PeopleSoft Process Monitor Process Detail page in the Update Process component.

    Select from the following options:

    • Owner: For a process launched by a user who has this process profile permission list assigned, only the user who launched the process can update it.

      For example, nobody else can restart a request that this user submitted. However, this user might still be able to update another user's processes.

    • All: All users can update processes that are launched by a user who has this process profile permission list assigned.

    • None: No one can update processes that are launched by a user who has this process profile permission list assigned.

Note: Be careful as you grant update authority to submitted processes. An inexperienced user can easily disrupt batch processing by deleting or holding processes, especially when restarting processes. If a program is not coded for a restart, then users should not be able to restart it. Restarting a program that is not properly coded to acknowledge the previous program run can threaten data integrity. Remember, the process profile permissions are based on the profile of the user who is submitting the process, not the user viewing the process monitor.

The Allow Requestor To options apply to using PeopleSoft Process Monitor and PeopleSoft Process Scheduler Request pages. These options enable you to restrict the authority that a user has while monitoring scheduled processes.

Override Output Destination

Select to allow a user to change the value in the Output Destination column on the Process Scheduler Request page.

Override Server Parameters

Select to enable users to select the server name and modify the run date/time group on the Process Scheduler Request page.

View Server Status

Select to enable users to access the Server List page in PeopleSoft Process Monitor.

Update Server Status

Select to allow a user to suspend, restart, or bring down a server using the Server Detail page from the server list in PeopleSoft Process Monitor.

Enable Recurrence Selection

Select to enable a run recurrence value for processes and jobs scheduled to run on the server.

Setting Sign-on Time Permissions

Access the Permission Lists - Sign-on Times page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Sign-on Times tab).

Image: Permission Lists - Sign-on Times page

This example illustrates the fields and controls on the Permission Lists - Sign-on Times page.

Permission Lists - Sign-on Times page

Pick a day and set a sign-on duration.

Sign-on times use the 24-hour clock and run through the end time value. For example, a user with an end time of 16:30 can use the system until 4:31 p.m.

To create a sign-on time that spans multiple days, use adjoining sign-on times. For example, to create a sign-on time running from 8 p.m. Tuesday to 6 a.m. Wednesday, you need a Tuesday start time of 20:00 and end time of 23:59. Then you need to add a Wednesday sign-on time with a start time of 00:00 and an end time of 05:59.

By default, all start times are 00:00 and end times are 23:59, and all days are listed. Delete days and change the times to restrict access.

A single day can have more than one sign-on period as long as the periods do not overlap. If a single day has multiple non-overlapping sign-on periods, then that day appears once for each period.

Setting Component Interface Permissions

Access the Permission Lists - Component Interfaces page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Component Interfaces tab).

Image: Permission Lists - Component Interfaces page

This example illustrates the fields and controls on the Permission Lists - Component Interfaces page.

Permission Lists - Component Interfaces page
Name

Shows the name of the component interface.

Edit

Click to access the Component Interface Permissions page and grant access to a particular component interface method.

Click the Edit button to authorize individual methods in each component interface:

Image: Component Interface Permissions page

This example illustrates the fields and controls on the Component Interface Permissions page.

Component Interface Permissions page
Method

Displays each method created within the component interface.

Method Access

Select from these two types of authorization:

Full Access: The method is authorized.

No Access: The method is not authorized.

Full Access (All)

Grants full access to all scripts listed on the page.

No Access (All)

Denies access to all scripts listed on the page.

You grant access to component interfaces similarly to adding page access. Add a new row to insert a component interface into the definition list. You must also grant access to the component interface methods.

After adding a new permission to a component, you must delete the web server cache for users to access the component through the portal. To delete the web server cache, reboot the web server.

Note: If more than one JVM services the web server, then rebooting the web server only purges the in-memory cache. No procedure exists to specify which JVM receives the request. For this reason, you must reboot all JVMs that service the web server.

Setting Web Library Permissions

Access the Permission Lists - Web Libraries page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Web Libraries tab).

Image: Permission Lists - Web Libraries page

This example illustrates the fields and controls on the Permission Lists - Web Libraries page.

Permission Lists - Web Libraries page

A web library is a derived/work record whose name starts with WEBLIB_. All PeopleSoft iScripts are embedded in records of this type. An iScript is a specialized PeopleCode function that generates dynamic web content.

Administrators should make sure that users have the proper access to web libraries. For example, the default navigation system for application users is implemented using a web library. If users do not have the proper authorization to the web library and its associated scripts, then they will not have proper access to the system. If users are not authorized for a particular web library or script, then they cannot invoke it.

After you add a web library, you set the access for each script function individually. Invoking an iScript requires the assembly of a URL. Developers assemble the URL using PeopleCode.

Web Library Name

Displays the web libraries added to the permission list.

Edit

Click to set access to web library functions. Select from these access rights for each function:

Full Access: Select this value to authorize the script.

No Access: Select this value to deny access to the script.

Click the Edit button to authorize each script in the web library:

Image: Weblib Permissions page

This example illustrates the fields and controls on the Weblib Permissions page.

Weblib Permissions page
Function

Displays each script stored in the web library.

Access Permissions

Click to set access to web library functions. Select from these access rights for each function:

Full Access: Select this value to authorize the script.

No Access: Select this value to deny access to the script.

Full Access (All)

Grants full access to all scripts listed on the page.

No Access (All)

Denies access to all scripts listed on the page.

View

Click to launch the content reference associated with the iScript.

Note: You must grant access to at least one script in the web library, otherwise the system removes the web library from the permission list when you leave the component—even if you save the component.

Setting Web Services Permissions

The web services offered by the PeopleSoft Integration Broker can be secured at the user ID level through the use of the web services permissions you specify. This applies to external web service requests only, not internal web service requests. Internal requests are those submitted from within your PeopleSoft system by a PeopleSoft user of one of your deployed PeopleSoft applications. External requests are those received from third party systems, such as other applications in your organization or other systems outside your organization sending requests over the internet.

If the user ID and password contained in the web service request has the appropriate permissions, the user can invoke the web service. If the submitted user ID and password fails authentication, the user has no permission to invoke the service. If only a User ID is provided, the PeopleSoft system attempts to verify if the user ID is a valid PeopleSoft user. If the verification fails, the system checks if the request is from a trusted node, and then uses the external user ID and password associated with the node from which the request was generated. If the request is not from a trusted node, the system checks the user ID associated with the ANONYMOUS node. How PeopleSoft Integration Broker handles authenticating web service request permissions is discussed in detail in the product documentation for PeopleTools: PeopleSoft Integration Broker.

Access the Permission Lists - Web Services page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Web Services tab).

Image: Permission Lists - Web Services page

This example illustrates the fields and controls on the Permission Lists - Web Services page.

Permission Lists - Web Services page

Add the web services to which a permission list should have access. Add and remove web services to and from the list using the standard plus and minus buttons.

Note: Web service requests contain user IDs. For the web service to be invoked, the submitted user ID must be valid in the PeopleSoft system. For example, the user account cannot be locked, the request must be submitted during the user ID's valid sign-on times, and the user ID must have permission to invoke the web service operation.

Web Services

Service

Displays the name of the web service defined in the PeopleSoft system.

Edit

Click to launch the Web Service Permissions page.

Full Access (All)

Click to grant full access to all services listed on the page.

No Access (All)

Click to set all services listed on the page to No Access.

Web Service Permissions

Access the Web Service Permissions page (click the Edit link on the Web Services page).

Image: Web Service Permissions page

This example illustrates the fields and controls on the Web Service Permissions page.

Web Service Permissions page
Service Operation

Each operation performed by the web service appears in the Service Operation list.

Access

Grant access to the operation by selecting Full Access. Deny access by selecting No Access.

Note: By default, the system sets the value to No Access. Make sure to modify the access values to reflect the desired level.

Setting Personalization Permissions

Access the Permission Lists - Personalizations page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Personalizations tab).

Image: Permission Lists - Personalizations page

This example illustrates the fields and controls on the Permission Lists - Personalizations page.

Permission Lists - Personalizations page

Note: Only those personalization options that accept customization are available for your users to modify.

Option Category Level

Displays the high-level grouping of personalizations.

Option Category Group

Shows the further categorizations of personalization options within the category level.

Edit Options

Click to access the Personalization Permissions page and enable specific personalization options for an option category group.

Personalization Permissions

When you click the Edit Options link, the Personalization Permissions page appears.

Image: Personalization Permissions page

This example illustrates the fields and controls on the Personalization Permissions page.

Personalization Permissions page
Category

Categorizes and encompasses a set of options for the end user. This field is display-only.

User Option

Displays the code associated with the user option. The code that the system (PeopleCode) recognizes at runtime. This field is display-only.

Description

Displays the description of the user option. This field is display-only.

Allow User Option

Select this check box to enable the user option.

Select All

Click this button to select the Allow User Option check box for each row in the grid.

Deselect All

Click this button to deselect the Allow User Option check box for every row in the grid.

See Understanding Personalizations.

Setting Query Permissions

Access the Permission Lists - Query page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Query tab).

Image: Permission Lists - Query page

This example illustrates the fields and controls on the Permission Lists - Query page.

Permission Lists - Query page

The Query page has links to the Permission List Access Groups page, where you can define the records to which the user can have access in PeopleSoft Query, and the Query Profile page, where you can define the query operations that the user can perform.

Defining Access Groups

Access the Permission List Access Groups page (click the Access Group Permissions link on the Permission Lists - Query page).

Image: Permission List Access Groups page

This example illustrates the fields and controls on the Permission List Access Groups page.

Permission List Access Groups page

Access groups are nodes in a query tree, which you build with PeopleSoft Query Manager. After you build a query tree, you give users access to one or more of its access groups. Then, they can generate queries on any tables in the access groups accessible to them.

When you open Query Manager, it displays either an access group structure or an alphabetical list of records to which you have access. Access groups enable you to logically organize the record components to control security access within PeopleSoft Query. This listing is not a physical representation of your database.

You can generate queries on and retrieve information only from the tables whose record definitions are within these access groups. If, for example, you were querying an order table and wanted to display data from a related table (like the customer name rather than the customer code), you must have both tables—the order table and the customer prompt table—in your access groups.

To create new queries, or even to run existing ones, users must have access rights to the record components used in the queries. After you build your query trees, you must grant users access to them. You can grant and restrict access to entire query trees or portions of them through the Access Groups page.

To add an access group to a permission list:

  1. Open the permission list and select Query, Access Groups Permissions.

  2. Select a tree name.

  3. Select the highest access group that the user can access.

    The system displays access groups in the selected query tree only.

    The access group that you select should be the highest-level tree group to which this permission list needs access. The Accessible check box is selected by default. For example, users in the ALLPANLS permission list have access to all record components in the EIS_ACCESS_GRP and all access groups below it in the QUERY_TREE_EIS query tree—in other words, to all record components in the tree.

  4. (Optional) Deselect the Accessible check box.

    To grant access to most of the record components in a high-level access group but restrict access to one of the lower-level groups, you can add a new row for the lower-level access group and deselect the Accessible check box. Users can then access all record components within the higher-level group except for those you explicitly made inaccessible.

    Note: Because it hinders system performance, do not deselect the Accessible check box for lower-level access groups. To restrict access to record components on a particular branch of a tree, consider creating a new tree for those definitions. Attempting to expand an access group that is not accessible causes all access groups below that access group to be loaded into memory.

  5. Save your changes.

    Note: When the system loads an access group into memory for the first time, you will likely experience a small delay. This delay is the result of a physical database read for each record component that is associated with that access group. For this reason, do not group a large number of record components into a single access group.

Defining Query Profiles

Access the Query Profile page (click the Query Profile link on the Permission Lists - Query page).

Image: Query Profile page

This example illustrates the fields and controls on the Query Profile page.

Query Profile page

Query profiles specify available query operations. You can give users the right to run queries but not create them, or to create regular queries but not workflow queries, and you can restrict the SQL operations that users can perform. You control these options through the query profile.

Each permission list has its own query profile, and the combination of all permission lists that are assigned to a role determine the total query access for the role. User profiles inherit query access only through the roles that you assign to them.

Note: The first level of security is access to PeopleSoft Query itself. Not every user needs to create queries. You grant access to the Windows client of PeopleSoft Query by selecting the Query Access check box on the PeopleTools page of a permission list. You grant access to Query Manager by including the QUERY_MANAGER menu and its related components on the Pages page of a permission list.

You select at least one of the options in the PeopleSoft Query Use section of this page to give users query access.

PeopleSoft Query Use

Select from:

  • Only Allowed to run Queries:

    Select to prevent users from being able to create queries and restrict them from running PeopleSoft Query. The values of the remaining options in this group are irrelevant if you select this option.

    Note: If you select this option, it only applies to the current permission list. If a user has permission to create public queries through another permission list, then that user can run and create queries against the cumulative set of tables specified through all access groups. For example, assume permission list X has Only Allowed to run Queries selected and is limited to tables A, B, and C. Also assume that permission list Y has Allow creation of Public Queries selected and is limited to tables B, C, and D. If a user ID has both permission list X and Y associated with it through roles, then that user can create Public Queries with tables A, B, C, and D.

  • Allow creation of Public Queries:

    Select to enable users to create public queries.

  • Allow creation of Workflow Queries:

    Select to enable users to create workflow queries in addition to private queries. A workflow query is used in PeopleSoft Workflow, either as a database agent query or a role query. These queries can circumvent security restrictions; the system does not check access group rights while running the query. To make sure that users cannot bypass system security, deselect this check box.

  • Maximum Rows Fetched:

    Enter a number to restrict the number of rows retrieved by a query. Some queries can return many data rows. For performance or time considerations, you may want users to view only some of those rows rather than all of them.

PeopleSoft Query Output

Select at least one of these values:

  • Run:

    PeopleSoft Query displays the query results in a view-only grid control. This option is useful as users are refining their queries.

  • Run to Excel:

    PeopleSoft Query passes the query results to Microsoft Excel, where users can analyze the results further.

 

Note: If using PeopleSoft Query in the Microsoft Windows environment, you grant runtime access through PeopleSoft Navigator by selecting at least one of the PeopleSoft Query output options.

Advanced SQL Options

Restrict less experienced users from generating complex queries, as such queries can affect system performance.

Setting Mass Change Permissions

Access the Permission List - Mass Change page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Listsand click the Mass Change tab).

Image: Permission List - Mass Change page

This example illustrates the fields and controls on the Permission List - Mass Change page.

Permission List - Mass Change page

Mass change operator security controls:

  • What mass change templates a user can access to create new definitions.

  • Whether a user can run mass change definitions online.

  • What mass change definitions a user can open, view, or run.

    These definitions must also be based on a template with the same PeopleSoft owner as the user.

Note: Users inherit mass change authorizations through their primary permission lists, not through roles.

Before you can use a new template to create definitions, you must have permission to access it.

To modify mass change template permissions:

  1. Add or remove templates from the Mass Change Template ID list.

  2. Select or deselect OK To Execute Online, as needed.

    When you have enabled the OK To Execute Online option, users with the given primary permission list can run mass change definitions after saving any modifications to the Mass Change Definitions pages.

  3. Save your work.

Viewing When a Permission List Was Last Updated

Access the Permission List - Audit page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Audit tab).

Image: Permission List - Audit page

This example illustrates the fields and controls on the Permission List - Audit page.

Permission List - Audit page

Use the Permission List - Audit page to view when a permission list was last updated and by whom. You can also view who has made changes to security tables by using the Database Level Auditing feature.

Setting Data Migration Permissions

Access the Permission List - Data Migration page (select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Data Migration tab.

Image: Permission List - Data Migration page

This example illustrates the fields and controls on the Permission List - Data Migration page.

Permission List - Data Migration page

The Data Migration page has links to the Access Group Permissions page, where you can define the records to which the user can have access in the Data Migration Workbench, and the Copy Compare Permissions page, where you can define the copy and compare operations that the user can perform.

For more information about these settings, see Setting Data Migration Permissions.

Assigning Search Group Permissions

Access the Search Groups page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Search Groups tab).

Image: Permission Lists – Search Groups

This example illustrates the fields and controls on the Permission Lists – Search Groups.

Permission Lists - Search Groups

Use the Permission Lists – Search Groups page to assign search groups to permission lists.

To assign search groups to a permission list:

  1. Click the Search Group Name lookup button to search for and select a search group to add to the permission list.

  2. To specify additional search groups, click the Add button and select a search group for each row that you insert.

  3. Click the Save button.

Running Permission List Queries

Access the Permission List Queries page (select select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists and click the Permission List Queries tab).

Image: Permission List - Permission List Queries page

This example illustrates the fields and controls on the Permission List - Permission List Queries page.

Permission List - Permission List Queries page

Permission list queries provide detailed information regarding a permission, such as the user IDs and roles that are associated with a permission list. The available queries are documented on the page.

To run permission list queries:

  1. Click the link associated with the query that you want to run.

    A new browser window opens.

  2. View the information the query returns or click a download results link.

    Note: The size of the file appears in parentheses beside the download options.

    For downloading, you have the following options:

    • Microsoft Excel spreadsheet.

      Downloads the query results as a Microsoft Excel spreadsheet (.xls) file.

    • CSV text file.

      Downloads the query results as a Comma-Separated Value (.csv) file.

    • XML file.

      Downloads the query results as an Extensible Markup Language (.xml) file.