Search Results get_role_functions




Overview
Explore in AI Chat

Overview

APPS.EGO_DATA_SECURITY is the central PL/SQL API within Oracle E-Business Suite that implements the Product Information Management (PIM) and Oracle Product Hub object-level data security model. While Oracle EBS provides function-level security through the standard FND security framework, EGO_DATA_SECURITY extends that model to the level of individual object instances, allowing grants of functions to be applied not just to a user or role globally, but to specific instances of a business object — for example, to a specific item, item catalog, or change order. The package resolves whether a given user is permitted to perform a specific function on a specific object instance, and it also generates the SQL predicate fragments used to filter query results by data security. This enables organizations to restrict visibility and update rights on a row-by-row or record-by-record basis, a requirement common in engineering, product data management, and collaborative development environments where item ownership or catalog scoping must be enforced.

The package is owned by APPS and is classified as OTHER in the ETRM API registry. It is referenced by 27 other packages, confirming its role as a foundational security utility consumed across the PIM and related modules.

Key Procedures and Functions

The package exposes 20 documented procedures and functions. The most directly relevant to the user's search are the inheritance and lookup routines:

  • CHECK_FUNCTION — Determines whether a user is granted a particular function for a particular object instance; returns a one-byte result code (granted, not granted, or error).
  • CHECK_INHERITED_FUNCTION — Extends CHECK_FUNCTION by evaluating grants that may be inherited through role or object hierarchies rather than directly assigned.
  • GET_FUNCTIONS — Returns the set of functions granted for a given object or object instance.
  • GET_INHERITED_FUNCTIONS — Returns the set of functions a user holds on an object instance when inheritance through role mappings and parent objects is included. This is the function users most often search for when troubleshooting why a user can see or act on a record.
  • GET_SECURITY_PREDICATE and its variants GET_SEC_PREDICATE_WITH_EXISTS and GET_SEC_PREDICATE_WITH_CLAUSE — Produce SQL WHERE-clause fragments that enforce data security directly in a query, enabling row-level filtering without procedural checks per row.
  • GET_INHERITED_PREDICATE — Generates a security predicate that accounts for inherited grants.
  • GET_INSTANCES and CHECK_INSTANCE_IN_SET — Resolve the object instances within a set and test membership, supporting instance-set-based security.
  • CREATE_ROLE_MAPPING, UPDATE_ROLE_MAPPING, and DELETE_ROLE_MAPPING — Maintain the mapping between roles and object instances that drives inheritance behavior.
  • GET_ROLE_FUNCTIONS — Returns the functions associated with a role mapping.

Tables Accessed

The package reads and writes several security and object metadata tables through APPS synonyms:

  • EGO_OBJ_ROLE_MAPPINGS — Stores the role-to-object-instance mappings manipulated by the role mapping procedures.
  • FND_GRANTS — Holds the actual function grants, including GRANTEE_KEY values matched against the optional p_user_name parameter.
  • FND_FORM_FUNCTIONS, FND_MENUS, and FND_MENU_ENTRIES — Provide function and menu metadata used to validate and expand function grants.
  • FND_OBJECTS — Defines the objects and their primary key ordering used to interpret the p_instance_pk1..5 values passed by callers.
  • FND_OBJECT_INSTANCE_SETS — Defines instance sets tested by CHECK_INSTANCE_IN_SET.
  • FND_USER — Resolves the current FND user when p_user_name is null.
  • HZ_PARTIES, HZ_RELATIONSHIPS, and PER_ALL_PEOPLE_F — Support grantees expressed as party, relationship, or person keys, such as 'HZ_PARTIES:1234'.
  • PLITBLM — The standard PL/SQL table used for list-based lookups.

Usage Notes

EGO_DATA_SECURITY is typically invoked through the object-level security framework rather than called directly by end users. Oracle Forms in Product Hub and PIM call CHECK_FUNCTION and CHECK_INHERITED_FUNCTION to decide whether to display secured blocks or permit update actions, and they rely on GET_SECURITY_PREDICATE variants to filter LOVs and query results. Concurrent programs and data migration scripts that read PIM objects use GET_INHERITED_FUNCTIONS or the predicate functions to honor the same security model outside the Forms runtime. Custom code should call the package rather than querying FND_GRANTS directly, because inheritance and instance-set logic are encapsulated here; invoking the API ensures consistent behavior across patch levels. When p_user_name is omitted, the package defaults to the current FND user, which is the normal pattern inside Form-based transactions, while batch and integration code must pass the grantee explicitly. Because the package is referenced by 27 other packages, changes to its behavior ripple across the PIM security stack, and administrators troubleshooting access issues should verify grants in FND_GRANTS and mappings in EGO_OBJ_ROLE_MAPPINGS before assuming the API is at fault.