Using Query Access Group Trees
With PeopleSoft Query security, you can control the query operations that users can perform and the data to which they have access.
PeopleSoft Query uses query access group trees to control security of the tables in your PeopleSoft database. You define a hierarchy of record components, based on logical or functional groupings, and then give users access to one or more branches of the tree. Users can use PeopleSoft Query to retrieve information only from those tables whose record definitions they have access to.
Using PeopleSoft Query Access Manager, you can create, view, and update query access group trees.
Query access group trees contain two types of nodes: groups and records.
Groups represent of a set of child groups or records.
Records represent a PeopleSoft record definition.
Use the Query Access Manager page (PSTREEMGRACC) to create query trees or search for existing query trees.
Navigation
Image: Query Access Manager page - example of a query access group tree
This example illustrates the fields and controls on the Query Access Manager page.
PeopleSoft provides sample trees with all of its applications. You can configure these trees; however, because these trees may get replaced when you upgrade to subsequent application releases, you should create your own query trees based on your organization’s needs.
In your query trees, include all record components that you want users to be able to query. Note that you do not have to put all record components in the same query tree. Instead, you can use the sample query trees to provide access to the standard PeopleSoft record definitions, but create additional query trees for record definitions that you want to add while adapting your system. This strategy enables you to take advantage of the sample trees but avoid overwriting your changes during future application upgrades.
How you organize the contents of your query trees depends on the needs of your organization and users. For example, for nontechnical or casual users, you might want to create small trees that are not intimidating.
To simplify the trees, you can create separate trees that contain subcategories of each function. For example, you could create separate trees for human resources, general ledger, and projects record components so that users in each region can access only those record components that they use.
When creating your tree, you should also have an access group that includes all components of the tree. This enables you to give users access to all tables more easily—you need only to add one row on the Access Groups tab in Query Security.
Note: Consider adding record components to your query trees in a hierarchy that matches the parent/child relationship of records in your database. Although you do not have to organize records in this way—PeopleSoft Application Designer actually controls the parent/child hierarchy in your database—you will probably find it helpful to keep your query trees consistent with your database structure.
After you have built a query tree, you must give users access to one or more of its access groups. They can then generate queries on any tables in the access groups that are accessible to them.
To create new queries, or even to run existing ones, users must have access rights to the record components that are used in the queries. After you have built 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 Permission List Access Groups page (by selecting
An optional batch process is available for users who work with Query Manager and PS/nVision. The system can much more quickly retrieve the queries that match the designated search criteria if the query access list cache is enabled.
Image: Query Access List Cache page
This example illustrates the fields and controls on the Query Access List Cache (RUN_QRYACCLIST) page.
To enable the query access list cache:
Select
Select the Enable Access List Cache option.
Click the Run button to run the process.
If the process does not finish, the cache will be disabled.
Note: When the Enable Access List Cache option is selected and roles of a user profile or permission list of a role has been modified, which affect the Query Access List Cache, you must rerun the QRYACCLIST AE process to properly update the cache. Otherwise, the Query Access List Cache is not up-to-date and will be switched off automatically.
Rerun the process when changes have been made to Query Access Groups or Query Access Group settings on Roles or Permission Lists.