Search Results rrs_edit_hier




Overview
Explore in AI Chat

Overview

RRS_SECURITY_PUB is a public PL/SQL package body in the APPS schema that implements role-based access control (RBAC) for Oracle EBS Release Management / Site and Hierarchy objects. It belongs to the ETRM (Enterprise Transaction and Reference Model) family of application modules and is classified as a PUB API, meaning its procedures and functions are intended to be callable from other Oracle EBS components, forms, and customer extension code. The package centralizes privilege evaluation so that any caller can determine, at runtime, whether the currently logged-in user holds VIEW or EDIT rights on a specific managed object. It abstracts the underlying role and function grant model behind a small set of boolean-returning functions that return FND_API.G_TRUE or FND_API.G_FALSE.

The package header comment identifies it with the RRSPSECB.pls source file, last revised in December 2010, confirming availability across both 12.1.1 and 12.2.2 instances. The package is referenced by two other packages, indicating that security checking is invoked as a shared service rather than being duplicated across callers.

Key Procedures and Functions

  • CHECK_OBJECT_VIEW_PRIVILEGE — Determines whether the current user may view a named object instance. It is a thin wrapper that delegates to CHECK_OBJECT_PRIVILEGE with a privilege type of 'VIEW'.
  • CHECK_OBJECT_EDIT_PRIVILEGE — Determines whether the current user may edit a named object instance. It delegates to CHECK_OBJECT_PRIVILEGE with a privilege type of 'EDIT'.
  • CHECK_OBJECT_PRIVILEGE — The core object-level evaluator. It first inspects the RRS_ROLE_BASED_SECURITY_ENABLED profile option; if the profile is 'N', security checking is skipped and the function returns FND_API.G_TRUE. Where RBAC is active, it maps the requested privilege and object name to the corresponding internal privilege name (for example, RRS_VIEW_SITE, RRS_VIEW_HIER, RRS_EDIT_SITE, RRS_EDIT_HIER). For EDIT privileges, a VIEW privilege is evaluated first, and EDIT is denied if VIEW fails. The result is ultimately obtained from EGO_SECURITY_PUB, the shared security engine.
  • CHECK_UDA_VIEW_PRIVILEGE — Provides the equivalent VIEW privilege check for User-Defined Attribute (UDA) objects, applying RBAC rules specific to the attribute group model.
  • CHECK_UDA_EDIT_PRIVILEGE — Provides the EDIT privilege check for UDA objects, again enforcing the view-before-edit rule.
  • CHECK_UDA_PRIVILEGE — The shared internal evaluator for UDA privileges, analogous in structure to CHECK_OBJECT_PRIVILEGE but scoped to attribute group and UDA entities.

Tables Accessed

Three underlying objects are documented for this package. EGO_ATTR_GROUP_DL is accessed through APPS synonyms and supplies attribute group definition data used when resolving UDA-level privileges. FND_FORM_FUNCTIONS supports the standard Oracle EBS function-security model, where menu functions are granted to responsibilities and evaluated during security checks. DBMS_OUTPUT is used for diagnostic trace output; the source shows PUT_LINE calls on the defensive branches that document unreachable code paths, which aids debugging but produces no user-visible behavior. The package also references EGO_SECURITY_PUB, the underlying security engine that performs the definitive grant resolution, and reads the FND_PROFILE value RRS_ROLE_BASED_SECURITY_ENABLED.

Usage Notes

RRS_SECURITY_PUB is typically invoked from Oracle Forms or OA Framework pages that display or modify RRS site and hierarchy data, and from concurrent programs or custom PL/SQL that must enforce the same access rules. Callers use it as a gate: before rendering an editable field or processing a save, the appropriate CHECK_* function is called and a false result suppresses the action or raises an error. Because the RBAC profile option is evaluated on every call, administrators can enable or disable role-based enforcement globally without code changes; when RRS_ROLE_BASED_SECURITY_ENABLED is 'N', all checks return true, preserving backward compatibility with responsibilities configured prior to RBAC rollout. Customizations should call the public functions rather than query the underlying tables directly, ensuring consistent evaluation and immunity to internal changes.