Search Results check_object_view_privilege




Overview

APPS.RRS_SECURITY_PUB is a public PL/SQL package within the Oracle E-Business Suite (EBS) Release 12.1.1 / 12.2.2 environment that supports the security model of the Rapid Reference Solution (RRS) framework. RRS is the underlying infrastructure that powers Oracle's attribute-driven user interfaces, most notably the Product Information Management (PIM) attribute panes, hierarchy browsing components, and User Defined Attribute (UDA) maintenance screens. Business users interact with these components whenever they view or edit item attributes, category attributes, or UDA-defined fields in forms such as the Item Master and the Attribute Management screens.

The package, owned by the APPS schema and carrying a status of VALID, encapsulates the privilege-checking logic that determines whether a given user may view, edit, or otherwise manipulate a particular object or UDA. Rather than embedding security checks throughout each RRS component, the framework centralizes them in this public API, allowing the attribute pane, hierarchy, and related modules to invoke a consistent, reusable validation layer. Because the package is classified as PUB, it is intended as a supported integration point and may be referenced by customizations and extensions that extend the RRS framework.

Key Procedures and Functions

The package exposes six documented procedures and functions, all dedicated to authorization checks:

  • CHECK_OBJECT_VIEW_PRIVILEGE — Determines whether the current user holds view privileges for a specified object within the RRS framework. It is the typical gatekeeper invoked before an object's data is rendered.
  • CHECK_OBJECT_EDIT_PRIVILEGE — Evaluates edit privileges for a designated object, governing whether the user may modify the object's definition or associated data.
  • CHECK_OBJECT_PRIVILEGE — A general-purpose object privilege check, typically used where a single call must validate access irrespective of whether the operation is a view or an edit.
  • CHECK_UDA_VIEW_PRIVILEGE — Verifies view access for a specific User Defined Attribute, ensuring that attribute values are only displayed to authorized users.
  • CHECK_UDA_EDIT_PRIVILEGE — Verifies edit access for a UDA, controlling whether a user may change the attribute's value or its setup.
  • CHECK_UDA_PRIVILEGE — Provides a consolidated UDA privilege check, used when the calling component does not need to distinguish between view and edit validation.

Each routine is designed to return or signal a boolean-style authorization result to its caller. No parameter lists are documented in the ETRM metadata, so the exact signatures are not reproduced here.

Tables Accessed

The package reads from the following documented tables and objects (accessed through APPS synonyms):

  • EGO_ATTR_GROUP_DL — Stores the attribute group definition records that drive RRS attribute panes. The privilege routines consult this table to resolve the object context against which security is evaluated.
  • FND_FORM_FUNCTIONS — The standard Oracle Application Object Library table of form functions. It is used to map the RRS feature being checked to the responsibility-level function grants that determine user permissions.
  • DBMS_OUTPUT — The Oracle-supplied debugging package, referenced for diagnostic output during privilege evaluation.

Additionally, the package references the SYS.STANDARD package, which is expected for any PL/SQL unit and does not indicate a business dependency.

Usage Notes

RRS_SECURITY_PUB is typically invoked indirectly rather than called directly by end users. Its documented dependents are the RRS_ATTR_PANE and RRS_HIERARCHY_INFO packages, which are the runtime drivers behind the RRS attribute pane and hierarchy user interfaces. When a user opens a form region that renders an RRS attribute pane or hierarchy, the framework calls into RRS_SECURITY_PUB to validate the user's rights before displaying or permitting edits.

Because the package is classified as PUB and is owned by APPS, developers extending the RRS framework may call these procedures from custom PL/SQL to enforce the same privilege model. The package has no dependency on concurrent program submission; it is a synchronous, callable API. Custom code should treat the CHECK_* routines as read-only validators and should not expect them to raise exceptions as the sole means of denial—callers are expected to branch on the returned privilege status. When troubleshooting missing or grayed-out attribute data, administrators can enable DBMS_OUTPUT to capture the package's diagnostic trace and confirm whether a privilege check, rather than a data issue, is suppressing the display.