New to psLens? This page documents one specific report. To see how it runs in the product, what
the output looks like, and how teams use it in practice, start with a live walkthrough.
## PeopleTools Access Audit Report
**Report ID:** `security-peopletools-access`
**Category:** Security
**Default Parameter:** `activeOnly = false`
## Purpose
Special PeopleTools access (Application Designer, Data Mover, Object Security, Query, Import Manager, 2-Tier Client) is granted on the PeopleTools tab of a permission list and recorded in `PSAUTHITEM`. This report lists every user who holds any of that access and the path that grants it: permission list to role to user.
## What It Detects
For each PeopleTools application, the permission lists that grant it, the roles that carry those permission lists, and the users in those roles. Each grant is marked **Full** (edit) or **Read-only** based on `PSAUTHITEM.DISPLAYONLY`. Each user is marked **Active** or **Locked** from `PSOPRDEFN.ACCTLOCK`.
The tools tracked are the `MENUNAME` values PeopleSoft uses for standalone tools access:
- `APPLICATION_DESIGNER` — Application Designer
- `OBJECT_SECURITY` — Object Security (Definition Security tool)
- `DATA_MOVER` — Data Mover
- `IMPORT_MANAGER` — Import Manager
- `QUERY` — Query
- `CLIENTPROCESS` — 2-Tier Client
## Tables Queried
- `PSCLASSDEFN` — permission list names and descriptions.
- `PSAUTHITEM` — tools access grants (`MENUNAME`, `DISPLAYONLY`).
- `PSROLECLASS` — which roles include each permission list.
- `PSROLEUSER` — which users hold each role.
- `PSOPRDEFN` — account lock status (`ACCTLOCK`) and primary permission list (`OPRCLASS`).
- `PSOPROBJ` — Definition Security grants: permission list to object group, with `DISPLAYONLY` (edit vs read-only).
- `PSOBJGROUP` — object group membership (which definitions belong to a custom group).
## Report Output
Four sections:
1. **Summary** — count of permission lists and distinct users per tool, plus the total number of users with any special access.
2. **Access by Tool** — each tool with its permission lists (Full or Read-only), descriptions, and the roles that carry them.
3. **Access by User** — every in-scope user with their account status, the tools they hold and at what level, a **Def. Security** column (can they edit definitions), and the permission lists and roles that grant them.
4. **Definition Security (Object Security)** — object group grants (`PSOPROBJ`): which permission lists can edit or read the definitions in each object group, and which users that reaches via primary permission list and roles.
Permission lists, roles, and users link back to their psLens detail pages.
## Parameters
| Parameter | Default | Description |
| ------------ | ------- | ------------------------------------------------------------------ |
| `activeOnly` | `false` | When `true`, restrict the user sections to unlocked accounts only. |
## Interpreting Results
- **Full vs Read-only.** Read-only Application Designer access can open and inspect definitions but not save changes. Full access can modify them. Treat Full access in a production database as the higher risk.
- **Locked users.** Locked accounts still hold the grant. They appear so you can audit dormant access that would return if the account is unlocked. Set `activeOnly = true` to hide them.
- **Object Security.** Access to the Object Security tool lets a user change Definition Security itself, which governs which definitions developers can edit.
## Definition Security details
Holding Application Designer access lets a developer open the tool. What definitions they can edit is controlled by Definition Security object groups (`PSOBJGROUP`) linked to permission lists through `PSOPROBJ`. The `DISPLAYONLY` flag on that link is the difference between read-only and edit access.
The delivered **PEOPLETOOLS** object group holds the system definitions and is read-only by default. An **Edit** grant on it (`DISPLAYONLY = 0`) means the permission list can modify delivered PeopleTools objects in Application Designer — a high-privilege grant worth auditing.
The report applies these grants to users through both their primary permission list (`PSOPRDEFN.OPRCLASS`) and their roles, and labels which path reaches each user. Permission-list-level grants are reported exactly from `PSOPROBJ`; the user roster is the set reached through those permission lists.