Defining Permissions
This section discusses how to:
Set general permissions.
Set page permissions.
Set PeopleTools permissions.
Set process permissions.
Set sign in time permissions.
Set component interface permissions.
Set web library permissions.
Set web services permissions.
Set Application Services permissions.
Set personalization permissions.
Set query permissions.
Set mass change permissions.
Display additional links.
View when a permission list was last updated.
Set data migration permissions.
Assign search group permissions.
Work with definition security permissions.
Add permission lists to ACM templates.
Run permission list queries.
Access the Permission Lists - General page (select and click the General tab).
This example illustrates the fields and controls on the Permission Lists - General page.
Field or Control |
Description |
|---|---|
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 User ID/Password to be Emailed? |
Select to enable user to receive forgotten user IDs or 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 or user ID 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:
Entering a value of zero (0) is equivalent to selecting Never Time-out. In order for the Never Time-Out or Specific Time-out (minutes) settings to work for a user, every permission list for that user profile must have a non-zero value set for Specific Time-out (minutes). The time-out that will apply to the user profile is the highest value in all the permission lists. Any user profile with the PeopleSoft Administrator Role will ignore the time-out settings on any other permission list. Note: Because timeout limits are also controlled at the web server level, you will need to change the web server timeout values also. See Configuring Portal Security and PIA Timeouts. |
Access the Permission Lists - Pages page (select and click the Pages tab).
This example illustrates the fields and controls on the Permission Lists - Pages page.
This table describes the fields on the Pages page.
Field or Control |
Description |
|---|---|
Mobile Page Permissions |
Click to grant access to mobile application pages. Important! PeopleSoft Mobile Agent is a desupported 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:
This example illustrates the fields and controls on the Component Permissions page.
This table describes the fields on the Component Permissions page:
Field or Control |
Description |
|---|---|
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 Pages link, the Page Permissions page appears:
This example illustrates the fields and controls on the Page Permissions page.
This table describes the fields on the Page Permissions page:
Field or Control |
Description |
|---|---|
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:
Locate the menu name of the component to which you want to add access.
Click Edit Components.
The Components page appears.
Locate the component to which you want to grant access.
By default, when adding a new permission list, no components are authorized.
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.
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 desupported product. These features exist for backward compatibility only.
Select , and select the Pages page.
Click the Mobile Page Permissions link.
The Mobile Page Permissions page appears.
To add a new mobile page to the permission list, click the plus sign.
For the Mobile Page Name edit box, click the search button.
Search for and select the mobile page for which you need to grant access.
Click OK.
Save the permission list.
Access the Permission Lists - PeopleTools page (select and click the PeopleTools tab).
This example illustrates the fields and controls on the Permission Lists - PeopleTools page.
The PeopleTools Permissions section of this page applies to standalone PeopleTools applications. They are not PeopleSoft 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 Type Permissions, Tools Permissions, and Miscellaneous Permissions links enable you to provide more detail to PeopleSoft Application Designer access permissions.
Definition Type Permissions
Use the Definition Permissions page to control access to definition types in PeopleSoft Application Designer. If you want to control access to definition types at runtime, you must use the Definition Security tab to set the access permissions. For more information on setting runtime access permissions, see Working with Definition Security Permissions.
Access the Definition Permissions page (click the Definition Type Permissions link on the Permission Lists - PeopleTools page).
This example illustrates the fields and controls on the Definition Permissions page.
Field or Control |
Description |
|---|---|
Access Code |
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 access: 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). Note: Projects cannot be set to No access because Application Designer requires access to a project to launch successfully. |
Full Access (All), Read Only (All), and No Access (All) |
Click to set all definition types in the list to the same access level. |
Tools Permissions
Access the Tools Permission page (click the Tools Permissions link on the Permission Lists - PeopleTools page).
This example illustrates the fields and controls on the 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:
Change Control (select ).
Build/Data Admin (select ).
Language Translations (select ).
PeopleCode Debugger (select ).
SQL Editor (the PeopleSoft Application Designer utility for adding SQL objects and statements to applications and application engine programs).
Upgrade (select ).
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 Full Access (All), Read Only (All), or No Access (All) buttons to set across-the-board settings. Remember that every button affects every access level for the tools.
Field or Control |
Description |
|---|---|
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:
|
Build/Data Admin |
Control access to the Build and Tools, Data Administration menu items. Select from:
|
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).
This example illustrates the fields and controls on the 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 Full Access (All), Read Only (All), or No Access (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).
This example illustrates the fields and controls on the 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.
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.
Access the Permission Lists - Process page (select 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).
This example illustrates the fields and controls on the 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).
This example illustrates the fields and controls on the Process Profile Permission page.
Field or Control |
Description |
|---|---|
Server Destinations |
You can specify output variables when running processes or jobs on a server. You have the following options:
|
OS/390 Job Controls |
Note: This functionality is no longer supported. |
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:
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.
Field or Control |
Description |
|---|---|
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. |
Access the Permission Lists - Sign-on Times page (select and click the Sign-on Times tab).
This example illustrates the fields and controls on the 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.
Access the Permission Lists - Component Interfaces page (select and click the Component Interfaces tab).
This example illustrates the fields and controls on the Permission Lists - Component Interfaces page.
Field or Control |
Description |
|---|---|
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:
This example illustrates the fields and controls on the Component Interface Permissions page.
Field or Control |
Description |
|---|---|
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.
Access the Permission Lists - Web Libraries page (select and click the Web Libraries tab).
This example illustrates the fields and controls on the 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.
Field or Control |
Description |
|---|---|
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:
This example illustrates the fields and controls on the Weblib Permissions page.
Field or Control |
Description |
|---|---|
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.
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: Integration Broker.
See Implementing Web Services Security.
Access the Permission Lists - Web Services page (select and click the Web Services tab).
This example illustrates the fields and controls on the 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
Field or Control |
Description |
|---|---|
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).
This example illustrates the fields and controls on the Web Service Permissions page.
Field or Control |
Description |
|---|---|
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. |
Access the Application Services page (select and click the Application Services tab).
This example illustrates the fields and controls on the Permission Lists - Application Services page.
|
Field or Control |
Description |
|---|---|
|
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. |
|
App Service ID |
Select the ID for an Application Service defined in the PeopleSoft system. |
|
Root Resource |
Select the root resource for the Application Service. |
|
Index |
Select the index number for the Application Service. |
|
REST Method |
Select the HTTP REST method used by the Application Service. |
|
Access |
Grant access to the operation by selecting Full Access. Deny access by selecting No Access. |
See the information on managing Application Services in the Integration Broker product documentation.To perform a bulk update for Application Service permissions, see Setting Application Services Security.
Access the Permission Lists - Personalizations page (select and click the Personalizations tab).
This example illustrates the fields and controls on the Permission Lists - Personalizations page.
Note: Only those personalization options that accept customization are available for your users to modify.
Field or Control |
Description |
|---|---|
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.
This example illustrates the fields and controls on the Personalization Permissions page.
Field or Control |
Description |
|---|---|
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, which is 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 clear the Allow User Option check box for every row in the grid. |
Access the Permission Lists - Query page (select and click the Query tab).
This example illustrates the fields and controls on the 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).
This example illustrates the fields and controls on the 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:
Open the permission list and select Query, Access Groups Permissions.
Select a tree name.
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.
(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.
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).
This example illustrates the fields and controls on the 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.
Field or Control |
Description |
|---|---|
PeopleSoft Query Use |
Select from:
|
PeopleSoft Query Output |
Select at least one of these values:
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. Select one or more of these options:
|
Important! Mass Change is a desupported product. If you used Mass Change in previous PeopleSoft releases, it is strongly recommended that you use Application Engine instead. For more information on PeopleSoft Application Engine, see Application Engine
Access the Permission List - Mass Change page (select and click the Mass Change tab).
This example illustrates the fields and controls on the 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:
Add or remove templates from the Mass Change Template ID list.
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.
Save your work.
Access the Permission List - Links page (select and click the Links tab).
This example illustrates the fields and controls on the Permission Lists - Links page.
Use this page to access links to other pages within your PeopleSoft system. For example, perhaps a PeopleSoft application requires a specific security setting to be associated with a permission list. If this application-specific setting appears on a page not in PeopleTools Security, add a link to the application page so that anyone updating the permission list can easily navigate to it.
Note: The Links page is read-only. You create the inventory of links to pages that exist outside of PeopleTools Security by using the Security Links component ().
Access the Permission List - Audit page (select and click the Audit tab).
This example illustrates the fields and controls on the Permission Lists - Audit page.
Use the Permission Lists - 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.
Access the Permission List - Data Migration page ( and click the Data Migration tab.
This example illustrates the fields and controls on the Permission Lists - 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.
Access the Search Groups page (select and click the Search Groups tab).
This example illustrates the fields and controls on the Permission Lists – Search Groups page.
Use the Permission Lists – Search Groups page to assign search groups to permission lists.
To assign search groups to a permission list:
Click the Search Group Name lookup button to search for and select a search group to add to the permission list.
To specify additional search groups, click the Add button and select a search group for each row that you insert.
Click the Save button.
Use the Permission Lists – Definition Security page to:
Add definition groups assigned to a permission list.
Access the Definition Permissions page to define access to definition types.
Adding Definition Groups to Permission Lists
Use the Definition Security page to assign definition groups to a permission list.
Access the Definition Security page (, and click the Definition Security tab).
This example illustrates the fields and controls on the Permission Lists – Definition Security page.
Field or Control |
Description |
|---|---|
Permission List |
Displays the name of the permission list. |
Description |
Displays the description of the permission list. |
Definition Group |
Click the Lookup button to search for a definition group to assign to the permission list. |
Display Only |
Select the box to allow read-only access to the definition group for users belonging to the permission list. |
Definition Type RunTime Access |
Click the link to set definition type runtime access, which is described later in this topic. |
Note that the Group Content Summary – Group Permissions page features similar functionality and enables you to assign permission lists to definition groups.
Defining Definition Type RunTime Access
Use the Definition Permission page to define runtime access to definition types for a permission list.
Runtime access is needed so that applications designed to modify or alter managed objects (objects created in Application Designer) can use the GetDefinitionAccess() built-in function to restrict certain end-users from that functionality. With runtime access, applications can be designed to allow modifying Application Designer objects without allowing access to Application Designer.
Access the Definition Permissions page (click the Definition Type RunTime Access link on the Permission Lists - Definition Security page).
This example illustrates the fields and controls on the Definition Permissions page.
Grant runtime 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 runtime access to specific definitions, such as PeopleSoft Payroll Application Engine programs, using Definition Security.
Field or Control |
Description |
|---|---|
Access Code |
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). Note: Projects cannot be set to No access because Application Designer requires access to a project to launch successfully. |
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 (Windows Client).
Use the Permission Lists – ACM Templates page (PTACM_ACCESS) to define access to automated configuration management (ACM) templates to the PTPT4800 permission list.
Note: You can add access to ACM templates only to the PTPT4800 permission list.
To access the page select and click the ACM Templates tab.
This example illustrates the fields and controls on the Permission Lists – ACM Templates page.
Field or Control |
Description |
|---|---|
Permission List |
Displays the name of the permission list. |
Description |
Displays the description of the permission list. |
Template Name |
Click the Lookup button to search for an ACM template to assign to the permission list. |
Display Only |
Select the box to allow read-only access to the definition group for users belonging to the permission list. |
Access the Permission List Queries page (select and click the Permission List Queries tab).
This example illustrates the fields and controls on the 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:
Click the link associated with the query that you want to run.
A new browser window opens.
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.