> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/reports/access-and-permissions.md). # Access and permissions Who can open the report builder, what an owner and a super administrator may do with a report, how entity and field permissions work, which rules are not enforced in this release, and who may download ## What this is, and when you need it This page answers "may this person do that?" for the report builder: open the menu, see a report, run it, edit it, schedule it, delete it, use an entity, see a field, download a file. Read it before you roll the builder out to people other than administrators, and again when somebody reports a greyed-out button or a **No access** badge. It also says plainly which rules exist in the design but are **not enforced** in this release. If you only want to know why a card says **Full access** for everything, jump to [what is not enforced yet](#access-open-when-unknown). ## At a glance | Question | Answer in 2026.10.1 | | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Who sees the **Reports** menu | Everyone who can open the v2 Webconsole; there is no menu right of its own | | Who sees a report | Its owner and super administrators; everyone sees system templates | | Who edits, schedules or deletes a report | Its owner and super administrators; nobody edits a system template | | Who shares a report | Nobody; **Share** is disabled | | Who creates SQL data sources, opens the Job Monitor, retries a run, sees all users' files | Super administrators only | | Entity and field permissions | Defined (`REPORT_DATA_`, `REPORT_VIEW_PII`), shown as badges, **not enforced**: every field is open | | Who downloads a file | The requester, the report owner, users listed directly as subscribers, super administrators | ## Who can open the menu The **Reports** branch under Webconsole → **Audit & Reports** has no menu right of its own. The v2 Webconsole builds its menu in the application rather than from menu rows, and every entry is shown to every signed-in administrator. What gates the branch is what gates the v2 Webconsole itself: the content provider's URL pattern `/webconsole-v2/*`, which the OE-4602 migration grants to the same roles as the classic `/webconsole/*` pattern. Someone who can open `/webconsole-v2/` can open **Reports**, **Data Catalog** and **Downloads**; whether they can do anything there is decided per report, per entity and per file, as below. **Job Monitor** is the exception: the page itself refuses anyone who is not a super administrator. ## Super administrators A super administrator is any user entitled to the resource named by the property `org.openiam.ui.super.admin.resource` in `openiam.ui.properties`, shipped as `SUPER_ADMIN`. The Webconsole finds out whether you are one by calling the Job Monitor's statistics endpoint: a 200 means yes, a 403 means no. That single answer switches on everything in the next list. Only a super administrator can: * open the **Job Monitor**, and **Retry** a failed run from there or from Run history; * **Cancel** a run that somebody else requested (the requester can always cancel their own); * create or change an **SQL data source**; everyone else sees the SQL mode greyed out and an existing SQL source read-only; * see every report in **My reports**, not only their own, and edit, schedule or delete it; * see **Show files from all users** in the Download center and manage anybody's files; * edit or delete a view they do not own. A super administrator still cannot edit, delete or schedule a system template, and cannot share a report. Nothing in the builder makes a super administrator see more fields than anyone else; see [what is not enforced yet](#access-open-when-unknown). ## Rights on a report Every report has one **owner**: the person who created it or cloned it. The facade computes the rights once per request and the screens hide or grey out what you may not do. | Action | Owner | Super administrator | Any other user | On a system template | | ------------------------------------------------------- | ------------------------------------- | ------------------- | -------------- | -------------------- | | See the report in the list and open its details | Yes | Yes | No | Everyone | | **Run**, **Export CSV** / **Export Excel**, **Preview** | Yes | Yes | No | Everyone | | **Clone** / **Clone to my reports** | Yes | Yes | No | Everyone | | **Edit** (the designer) | Yes | Yes | No | Nobody | | **Schedule** / **Edit schedule** / **Remove schedule** | Yes | Yes | No | Nobody | | **Delete** | Yes, when no run is queued or running | Yes, same condition | No | Nobody | | **Share** | Nobody | Nobody | Nobody | Nobody | Whoever may edit a report may manage its schedule; a schedule is never managed on its own. A report with an active run cannot be deleted; the **Delete** item says **A run of this report is queued or running. Wait for it to finish or cancel it first.** A system template says **System templates cannot be deleted.** The clone of a report belongs to whoever cloned it, and nobody can clone a report they cannot see, so there is no way to hand a report to another person in this release. When Dana Okafor wants a Compliance colleague to own **Contractor role access**, she saves its data source as a view; the colleague builds their own report on the view in a few steps, and owns that one. ### Views A view may be edited or deleted by its owner and by super administrators. Every view is listed for everyone on the Data Catalog's **Views** tab and may be read by any report, so a view is the one thing in the builder that is shared by default. It cannot be deleted while a report reads it or a run uses it. System views, the inline sources behind the shipped templates, are read-only. ### Runs A run may be cancelled by the person who requested it and by super administrators. Only super administrators retry one. A preview is bound to the person asking and is neither stored nor audited. ### System templates A system template is visible to everyone, can be run, previewed, exported and cloned by everyone, and can be changed, deleted or scheduled by nobody, super administrators included. The facade refuses first, so the screens never offer the actions; the report service refuses too, so the API cannot either. See [System templates](/administration-guide/reports/system-templates.md). ## Entity access Every catalog entity names a **data permission**, `REPORT_DATA_`: `REPORT_DATA_USER` for User, `REPORT_DATA_USER_ROLE` for User role membership, `REPORT_DATA_AUDIT_EVENT` for Audit event. The design makes each of those a resource of type **Report data** that an administrator grants like any other entitlement, directly or through a role, and that a user can ask for. With the permission, an entity's card reads **Full access** or **Partial**; without it, **No access**, the entity cannot be chosen as a main or related entity, and the wizard, the builder and the catalog show a **Locked** marker with a **Request access** link. The catalog never hides a locked entity: you are meant to see what exists and ask for it. ### Request access **Request access** on a locked entity opens SelfService at `/selfservice-v2/request-access?resource=`, with the entity's data permission filled in as the resource to request, so the request lands with whoever approves access to that resource. Approval follows the ordinary access-request flow; see [Configure requests and approvals](/administration-guide/requests.md). {% hint style="warning" %} Nothing in 2026.10.1 creates those resources. The permission names exist in the catalog seed and in the badges, but no migration seeds a `REPORT_DATA_USER` resource or a **Report data** resource type, so a request for one has nothing to be granted against until an administrator creates the resource by hand or a later release seeds it. Because permissions are not enforced either (next section), nobody is blocked by this today. {% endhint %} ## Locked fields and personal data Beyond the entity's permission, individual fields can require a further one. The shipped catalog uses a single such permission, `REPORT_VIEW_PII`, on the six fields that hold personal data: | Entity | Field | | -------------- | ------------- | | User | Date of birth | | User | Sex | | Email address | Email address | | Login | Last login IP | | Audit event | Client IP | | Orphan account | Email address | A field you may not use is **locked**: the wizard's **Fields** step and the designer's **Available** list show it with a lock and the hint **You do not have access to this field**, and it cannot be selected. User names, login names and employee IDs are not personal data in this sense and are never locked. The six fields have a second effect that **is** enforced: a file whose columns include one of them expires after at most 7 days, whatever the report's retention says, because the run records which permission-marked fields it read. Fields used only in filters do not count; a calculated field counts through the fields it reads. See [Retention](/administration-guide/reports/run-and-download.md#retention-pii). ## What is not enforced yet The report service decides access from the permissions the caller sends with each request. In this release the Webconsole facade sends **none**, on every request, and the service ships with {% code overflow="wrap" %} ```properties report.access.open-when-permissions-unknown=true ``` {% endcode %} which tells it to treat unknown permissions as "everything granted". The result: * every entity card reads **Full access** and **Request access** never appears; * every field, the six personal-data fields included, can be selected by anyone who can open the builder; * a run reads whatever its definition names, for anyone. The personal-data mark still shortens retention to 7 days, and the badges, the lock markers and the request link are all in place; they are simply never triggered. The change that makes the facade send real permissions, and turns the property off, is the ticket **RB28 / OE-5279** on epic OE-4442. Until it lands, treat the builder as a tool for administrators you would trust with the underlying databases. Setting the property to `false` now does not give you per-user enforcement: with no permissions sent, it locks the six personal-data fields for **everyone**, super administrators included, while entities stay open. That is a usable stop-gap if the personal-data columns must not be exported at all, and nothing else. ## SQL data sources An SQL data source runs an administrator's `SELECT` as written. The catalog's entity permissions and field locks do not exist inside it: whatever the statement returns is a field, and whatever rows it returns are rows. That is why: * only a super administrator can create one or change one; the view editor shows the SQL mode to nobody else, and an SQL source opened by anyone else is read-only with the notice **This view is an administrator SQL data source**; * every report over one carries the badge **Not subject to field and row filters** in the Reports list and in the catalog, so a reader knows the usual protections are off; * every file produced from one counts as personal data for retention and expires after at most 7 days; * the statement is checked to be one read-only `SELECT` (or `WITH … SELECT`) with no data changes, no session control and no procedure calls, it runs as the read-only reporting user, and every validation, save and run is audited. See [SQL data sources](/administration-guide/reports/views-and-sql-sources.md#sql-source). ## Downloads A file may be downloaded, from Run history, from the Download center or from the link in a delivery mail, by: * the person who requested the run; * the owner of the report; * a user listed **directly** as a subscriber of the report's schedule, for scheduled runs; * a super administrator. A download link always needs a sign-in; an external e-mail address therefore only ever receives the attachment, never a link. Keeping a file (**Keep file** / **Stop keeping**) and deleting one before it expires are for the report owner and super administrators; an export without a saved report is owned by whoever requested it. {% hint style="warning" %} A user who is a subscriber only **through a group** is not on the list. The group is expanded to its members when the mail is sent, so they receive the attachment or the link, but the link answers 403 for them. Until this is fixed, list such users directly as well as through the group, or keep the file under 10 MB so it is attached. {% endhint %} ## Sharing **Share** is in every report's row menu and is disabled with **Available in a later release**. The **Shared with me** tab is prepared in the Reports list but not offered. In this release the only way to give someone else "the same report" is to publish its data source as a view and let them build their own on it; ownership cannot be transferred. The schedule's **Subscribers** are a delivery list, not a share: a subscriber receives the file and can download it, and still cannot see the report. ## Audit Every create, change, clone, delete, run, export, cancel, retry, schedule change, delivery, download, keep and purge is written to the audit log with the report's name, never its ID, and a save records what changed per section. The action names are listed on [Operate the report service](/administration-guide/reports/operate-the-report-service.md#operate-audit-actions). ## When it goes wrong | Symptom | Likely cause | | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A colleague cannot see a report you built | Expected: a report is visible to its owner and super administrators only. Save its data source as a view and let them build their own report on it. | | **Edit**, **Schedule** and **Delete** are missing on a report | It is a system template (clone it), or you are neither its owner nor a super administrator. | | **Delete** is disabled with **A run of this report is queued or running** | Wait for the run to finish, or cancel it from Run history or the Job Monitor. | | **Job Monitor** says **Administrators only** | You are not entitled to the `SUPER_ADMIN` resource. | | The view editor has no **SQL query** tab | Only super administrators see it, and only while creating a new view. | | A subscriber clicks the link in the delivery mail and gets 403 | They receive the mail through a group and are not listed directly on the schedule, or they are an external address. List them directly, or keep the file under 10 MB so it is attached. | | Every entity shows **Full access**, personal-data fields included | Expected in this release; permissions are not sent and the service treats unknown permissions as open. | | **Request access** sends the user to SelfService but the request cannot be submitted | The `REPORT_DATA_…` resource does not exist yet; nothing seeds it in this release. | ## Related * [Report builder overview](/administration-guide/reports/overview.md) — the vocabulary this page uses * [Browse the Data Catalog](/administration-guide/reports/data-catalog.md) — the badges as the catalog shows them * [Run a report and download the file](/administration-guide/reports/run-and-download.md) — the Download center and retention * [Views and SQL data sources](/administration-guide/reports/views-and-sql-sources.md) — the administrator-only SQL source * [Operate the report service](/administration-guide/reports/operate-the-report-service.md) — the access property and the audit actions * [Configure requests and approvals](/administration-guide/requests.md) — where a **Request access** request goes --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/reports/access-and-permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.