Search Results fun_security




Overview
Explore in AI Chat

Overview

APPS.FUN_SECURITY is a server-side PL/SQL package that belongs to the Oracle E-Business Suite Financials foundation layer (the FUN prefix denotes the Financials common components shared across the subledgers). Its purpose is to centralize the evaluation of assignment-based and grant-based access control for financial transactions and master data. In the ETRM classification it is tagged as API classification OTHER, indicating that it is intended primarily for internal use by other Oracle application code rather than as a published, customer-facing API. The package is shipped in a VALID state in both Release 12.1.1 and 12.2.2 and resides in the APPS schema, so its routines execute with the privileges of APPS and rely on APPS synonyms for all external object references. Within the EBS security model, FUN_SECURITY acts as a rule engine that answers two fundamental questions on behalf of calling programs: whether a grant of access is valid, and whether a given user or role is permitted to perform the requested operation. It complements the Oracle Grants foundation tables (FND_GRANTS and related objects) and the Trading Community Architecture (HZ) party model, bridging generic function security metadata with transaction-level authorization requirements.

Key Procedures and Functions

The documented package exposes four callable units. No parameter lists are published in the metadata, so only their purpose is described here.

  • CREATE_ASSIGN — Establishes a new assignment record, that is, a mapping that grants or associates access rights to an entity within the security framework.
  • UPDATE_ASSIGN — Modifies an existing assignment, allowing access rights previously established to be changed or refreshed.
  • IS_ACCESS_ALLOW — The primary predicate routine. It evaluates the defined assignments and grants and returns an indicator of whether access should be permitted for the caller's context.
  • IS_ACCESS_VALID — A companion validation function that determines whether a given access definition or assignment is itself structurally valid, independent of the outcome of the allow check.

Together these four units provide the create, maintain, and evaluate lifecycle for access assignments, with IS_ACCESS_ALLOW and IS_ACCESS_VALID being the read-only evaluation entry points most frequently called at runtime.

Tables Accessed

The package reads and writes a mixture of Oracle Application Object Library, Grants, Trading Community Architecture, and Financials entity tables, all through APPS synonyms.

  • FND_GRANTS, FND_MENUS, FND_OBJECTS, FND_OBJECT_INSTANCE_SETS — the Grants foundation tables. FND_GRANTS stores the grant definitions themselves, while FND_MENUS, FND_OBJECTS, and FND_OBJECT_INSTANCE_SETS supply the menu, object, and instance-set metadata against which grants are defined and evaluated.
  • HZ_PARTIES, HZ_ORG_CONTACTS, HZ_ORG_CONTACT_ROLES, HZ_RELATIONSHIPS, HZ_PARTY_USG_ASSIGNMENTS — the TCA party model. These are used to resolve the organizations, contacts, contact roles, and party relationships that form the subject of customer- and supplier-facing access rules.
  • XLE_ENTITY_PROFILES — the legal entity and ledger context, used to scope assignments and access checks to the appropriate entity.
  • DUAL — used for singleton evaluations and constant returns.

The CREATE_ASSIGN and UPDATE_ASSIGN routines are the write paths (primarily touching assignment and grant data), while IS_ACCESS_ALLOW and IS_ACCESS_VALID perform read-only lookups across the join set above.

Usage Notes

FUN_SECURITY is referenced by one other Oracle package, FUN_TRX_PVT, which is the private transaction-handling package in the Financials common layer. This dependency indicates that access checks are performed during transaction processing, typically when a transaction's customer, contact, or entity must be validated against the caller's granted authority. Custom code should generally not call FUN_SECURITY directly, because it is classified OTHER and its interface may change between releases. Where transaction-level authorization is required, the supported route is through FUN_TRX_PVT or the standard transaction APIs that invoke it. Direct invocation from forms or concurrent programs is uncommon; when it does occur, it takes the form of embedded PL/SQL that evaluates IS_ACCESS_ALLOW before permitting a financial operation. Because the package runs as APPS, any custom wrapper must respect the same FND_GRANTS and HZ data model and must be granted execute privileges explicitly. As with all APPS-owned foundation packages, the body should be treated as Oracle proprietary and reviewed against the current Release 12.2.2 patch level before reliance in production customizations.