Search Results get_security_predicate_w_binds
Overview
FND_DATA_SECURITY is the core PL/SQL package that implements Oracle E-Business Suite's function and data security model. Declared with AUTHID CURRENT_USER, it evaluates whether a given user, responsibility, or role is authorized to perform a named function against a specific object instance. Rather than answering a simple "can this user open this form" question, the package resolves grants expressed at the object level — for example, whether a user may view or update a specific set of ledger, operating unit, or inventory records defined by primary key values in FND_OBJECTS.
In Release 12 the package hardcodes the constant DISALLOW_DEPRECATED to 'Y'. This is a deliberate architectural marker: any deprecated calling convention, most notably passing p_user_name to APIs that now derive identity from the session, raises a runtime exception immediately instead of silently emulating Release 11.5 behavior. Customizations migrated from 11i that still supply a user name will therefore fail fast, surfacing the incompatibility at development time rather than producing incorrect security outcomes in production. The same package is referenced by 51 other packages, which makes it one of the most heavily depended-upon security utilities in the application schema.
Key Procedures and Functions
The package exposes 18 documented routines. The central authorization entry point is CHECK_FUNCTION, which determines whether a user holds a grant for a particular function on a particular object instance; it accepts up to five primary key values corresponding to the primary key columns of the object as defined in FND_OBJECTS. CHECK_INSTANCE_IN_SET validates membership of an instance within an object instance set, while CHECK_GLOBAL_OBJECT_TYPE_GRANT and CHECK_USER_ROLE test broader grant and role conditions.
Metadata and introspection routines include GET_FUNCTIONS, GET_FUNCTIONS_BY_PROMPT, GET_MENUS, and GET_INSTANCES, which return the functions, menu entries, and object instances available to a caller. GET_ORIG_KEY supports key resolution for instance sets. The predicate-generation routines — GET_SECURITY_PREDICATE and GET_SECURITY_PREDICATE_W_BINDS — build the WHERE-clause fragments and associated bind variables that VPD (Virtual Private Database) policies and custom queries apply to restrict row-level access. GET_SECURITY_PREDICATE_W_BINDS returns the bind values alongside the predicate text, which is essential when the predicate must be executed through dynamic SQL where literal substitution would be unsafe or inefficient.
A group of UPGRADE_* utilities (UPGRADE_PREDICATE, UPGRADE_COLUMN_TYPE, UPGRADE_GRANTEE_KEY) and SUBSTITUTE_PREDICATE support migration and predicate transformation during patching and Release 12 upgrade activities. Small conversion helpers TO_INT and TO_DATE normalize string inputs into the numeric and date forms expected by the security tables.
Tables Accessed
The package reads FND_GRANTS, the authoritative repository of function and instance grants, together with FND_OBJECTS and FND_OBJECT_INSTANCE_SETS, which define object structures and the sets used to group instances. Function and menu metadata come from FND_FORM_FUNCTIONS, FND_COMPILED_MENU_FUNCTIONS, FND_MENU_ENTRIES_TL, FND_RESP_FUNCTIONS, and FND_RESPONSIBILITY. User and role identity is resolved through FND_USER and WF_LOCAL_ROLES. Utility dependencies include DBMS_SQL for dynamic predicate execution, DUAL, PLITBLM for PL/SQL table handling, and V$INSTANCE for instance identification in multi-node deployments.
Usage Notes
FND_DATA_SECURITY is invoked primarily by the Forms-based security layer when a responsibility attempts to open a function, and by concurrent programs and custom code that must enforce the same rules programmatically. Developers writing custom queries against secured objects typically call GET_SECURITY_PREDICATE_W_BINDS to obtain a predicate and its bind values, then execute the resulting SQL through DBMS_SQL or native dynamic SQL. Because DISALLOW_DEPRECATED is set to 'Y', all new and migrated code must rely on session context rather than passing p_user_name; doing so raises an immediate exception. The 51 dependent packages indicate that any modification to signature or semantics carries broad upgrade risk, so extensions should be built on top of the documented APIs rather than by altering the package.