Search Results delete_menu_entry

Overview

FND_FUNCTION_SECURITY_CACHE is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the "OTHER" API category. Its purpose is to maintain the integrity and freshness of the function security cache that governs which users, responsibilities, and security groups may access given functions, menus, and menu entries within the EBS application. The cache is the runtime structure consulted whenever a form or self-service page validates whether the current responsibility is permitted to invoke a function. Rather than requiring the cache to be rebuilt in full after every administrative change, the package exposes targeted maintenance procedures that invalidate or refresh only the affected cache entries.

The package header carries the revision marker AFFSCIS.pls 120.1, and its procedures are explicitly documented as being "invoked when" a corresponding security metadata change occurs. This confirms the package functions as a change-propagation layer: it is called after inserts, updates, and deletions against the underlying security tables so that the in-memory representation stays synchronized with the data model. Both EBS 12.1.1 and 12.2.2 retain this package, and the documented API surface lists twenty-seven procedures; the excerpts below name the grant-related members most relevant to the search term insert_grant as well as the surrounding function, menu, menu-entry, responsibility, security group, and user operations.

Key Procedures and Functions

The documented procedures follow a consistent naming convention: an action verb (INSERT, UPDATE, DELETE) paired with the security entity affected. Notable members include:

• INSERT_GRANT — invoked when a grant has been inserted; accepts the grant GUID, grantee type, and grantee key. This is the procedure matched by the user's search. By passing the composite grant identifier, it updates the cache so the newly granted privilege is recognized without a full cache reload.
• DELETE_GRANT and UPDATE_GRANT — the companion operations for removed and modified grants, taking the same grant-guid, grantee-type, and grantee-key identifiers.
• INSERT_FUNCTION, UPDATE_FUNCTION, and DELETE_FUNCTION — keyed on function ID, these maintain cache entries for the function registry itself.
• INSERT_MENU, UPDATE_MENU, and DELETE_MENU — keyed on menu ID, keeping menu-level cache nodes current.
• INSERT_MENU_ENTRY, UPDATE_MENU_ENTRY, and DELETE_MENU_ENTRY — keyed on menu ID, sub-menu ID, and function ID, maintaining relationships between menus and the functions or sub-menus they expose.
• INSERT_RESP, UPDATE_RESP, and DELETE_RESP — invoked on responsibility changes.
• INSERT_SECGRP, UPDATE_SECGRP, and DELETE_SECGRP — invoked on security group changes.
• INSERT_USER and DELETE_USER — invoked on user record changes that could affect cached security resolution.

The procedure names beyond entry twenty are not enumerated in the excerpt, but they follow the same entity/action pattern. No parameter signatures should be assumed beyond those shown; each procedure is deliberately narrow so callers pass only the identifiers needed to locate the affected cache node.

Tables Accessed

The documented table reference for this package is WF_PARAMETER_LIST_T, an Oracle Workflow parameter-list type accessed through an APPS synonym. Within this package the type is used as a structured input or internal working value when resolving grant, grantee, and function identifiers, rather than as a persistent application table. It supports the package's role as a cache-maintenance utility by providing a consistent shape for passing parameter sets to the cache logic. No direct DML against base security tables is documented for this package; the actual security definitions reside in the FND function, menu, responsibility, and grant tables, while this package is responsible for propagating changes to the cache layer that consumes them.

Usage Notes

FND_FUNCTION_SECURITY_CACHE is not intended for direct invocation by end users or casual custom code. It is the designated callback for security metadata maintenance and is referenced by eleven other packages in the EBS codebase, which call its procedures after performing DML on function security structures. Typical invocation paths include the standard Function Security and Menu administration forms, responsibility and security-group maintenance routines, and user provisioning flows. When a developer or administrator inserts a new grant through supported administrative screens, the framework ultimately routes that change through INSERT_GRANT so the cache reflects the new privilege.

Because the procedures are keyed on identifiers such as the grant GUID, grantee type, and grantee key, they are safe to call selectively and cheaply; a full cache rebuild is avoided. Custom integrations that manipulate function security data directly should mirror this behavior by calling the appropriate procedure — for example INSERT_GRANT after a grant insert — to prevent the cache from becoming stale. Failure to notify the cache can result in users gaining or retaining access that does not match the underlying security configuration. In both 12.1.1 and 12.2.2 the interface remains unchanged, so the same calling conventions apply across releases. The package should be treated as an internal maintenance API, and any customization should preserve the documented one-procedure-per-change pattern.