Enhancement Request- Please provide restriction capability on the new OAC feature, Shared Objects inside a subject area. This is required such that we can have control in Production to limit the over utilization of this feature.
Organizations with larger user database will face significant challenges if there’s no capability to restrict access to shared objects. Relying on users not to save the shared objects they create isn’t an effective or sustainable control. This feature needs a proper access-control mechanism, and Oracle has acknowledged this, aligning with our view. As a result, we consider this a high-priority enhancement.
The feature is available.
Subject Area > Inspect dialog will show a new Access tab that will allow you to set user/group permission as Full Control vs Write. You will see a Consume option in the UI which is bug and will be removed with September 2026 update.
We’ve identified the Consume option appears to be a defect: when we change a role’s subject area access from Write to Consume, it automatically reverts back to Write.
Our requirement is to retain full control over the “Share Objects” capability tied to subject areas in OAC solely to Admin users, particularly in Production. Given the size of our user base, we can’t allow users to freely create or modify objects based on individual needs, as this will quickly lead to an unmanageable set of artefacts.
Relying on user guidance to self-restrict object creation/editing isn’t a viable control for Production.
Only Administrators can update the Access permission on Subject Area > Inspect. Access tab will not be shown for non-admin users in the SA> Inspect dialog.
On Datasets, the dataset owner controls the Access.
Following the September 2026 software update, we observed that the Inspect dialog now provides only the Full Control and Write options. However, there’s still no capability to restrict access to shared objects created within a subject area.
As a result, a shared calculation created by one user can be edited and saved by another user. This isn’t appropriate for a production environment, as it could lead to users modifying one another’s calculations and creating unnecessary clutter.
We need more granular access controls to ensure that shared objects can be managed only by authorized users (Admin) and to maintain a controlled, well-governed production environment.
I am creating two tables in a freeform report and overlaying these tables to appear as one to the end user. I can hide the header titles by setting the font and highlight colour to the same as the background colour but it would be better if there was a functionality to disable the header row completely.
My organization needs a practical way to generate a comprehensive report listing all members—including both direct and inherited assignments—of every custom application role within the Oracle Analytics Cloud (OAC) Console’s Roles and Permissions area. Today, the only built‑in method is exporting one role at a time through…
Currently you are able to change the width of a field in a table or pivot table by dragging the border but there is no option to manually fix it to a set value e.g. 100px. Justification: I am creating a report with two tables in freeform and need the field widths to have the same size when I overlay one table on the other.…
Request for an enhancement to Oracle Analytics Cloud (OAC) Classic Analysis Selection Steps on measure suppression for a specific calculated member created through Selection Steps. This idea is opened based on the directions from oracle CEAL team, for more details please find the below service request. SR -…
Hi, We use a lot of Custom App Roles in OAC Console and It would be easier to have an API to manage the members of App Roles.
