Search Results is_root_rulefolder_locked

Overview

APPS.CZ_SECURITY_PVT is a private PL/SQL package body that implements the security, locking, and privilege enforcement infrastructure for Oracle E-Business Suite applications built on the Common UI (CZ) framework, most notably Oracle Configurator and its associated model-centric authoring tools. Rather than exposing a public API surface, the package serves as the back-end implementation layer for security behaviors that are surfaced to end users through Configurator and related CZ-based forms. Its principal responsibilities include resolving profile-option driven default access values, evaluating whether a given user holds a specific privilege over a given entity, granting and revoking privileges, and managing entity- and model-level locks that prevent concurrent modification of development objects such as models, UI definitions, rule folders, and publication artifacts.

The package is registered under owner APPS with an API classification of PVT, indicating that it is not intended as a supported public interface and that invocations should normally originate from within the CZ framework itself or from closely coupled CZ packages. The source header (czsecurb.pls 120.4, dated 2007/09/05) confirms its long-standing role in the 11i through 12.x code line, and it is referenced by eight other packages, reflecting its position as a shared security utility within the CZ subsystem.

Key Procedures and Functions

The 71 documented routines fall into three functional clusters:

• Profile and default resolution: GET_DEFAULT_ACCESS_PROFILE and GET_PROFILE_VALUE read profile option values (including DEFAULT_ENTITY_ACCESS) via FND_PROFILE.value to establish baseline access decisions used elsewhere in the package.
• Privilege management and evaluation: GRANT_PRIVILEGE and REVOKE_PRIVILEGE create and remove privilege records; HAS_PRIVILEGES and HAS_MODEL_PRIVILEGES evaluate whether a user or role holds the required rights against a target entity.
• Locking and concurrency control: LOCK_ENTITY, UNLOCK_ENTITY, UNLOCK_MODEL, LOCK_MODEL_STRUCTURE, UNLOCK_MODEL_STRUCTURE, and LOCK_UI_DEF acquire and release locks on CZ objects. The corresponding interrogatives — IS_LOCK_REQUIRED, IS_MODEL_LOCKED, IS_MODEL_STRUCTURE_LOCKED, IS_ROOT_UI_LOCKED, IS_UI_DEF_LOCKED, and ARE_MODELS_LOCKED — determine current lock state, including the specialized checks IS_ROOT_RULEFOLDER_LOCKED and IS_RULEFOLDER_LOCKED for rule-folder hierarchies.

These routines are the basis for the cz_ui_def_id lookups encountered by developers, since UI definition locking and privilege checks pivot on that identifier. The package raises an extensive set of named exceptions (for example ENTITY_LOCKED_BY_USER, ENTITY_LOCKED_OTH_USER, INVALID_PRIVILEGE, HAS_NO_LOCK_PRIV) that callers translate into user-facing error messages.

Tables Accessed

The package reads and writes CZ development and publication metadata through APPS synonyms:

• CZ_UI_DEFS, CZ_UI_NODES, CZ_UI_REFS, CZ_UI_TEMPLATES — UI definition structures whose lock state and access rights are evaluated; CZ_UI_DEFS underpins cz_ui_def_id checks.
• CZ_DEVL_PROJECTS — development-project ownership used to scope privileges and locks.
• CZ_LOCK_HISTORY, CZ_PUBLICATION_LOCKS — persistence of lock acquisition, release, and history.
• CZ_MODEL_REF_EXPLS — model reference explosion data supporting model-structure lock evaluation.
• CZ_PS_NODES, CZ_RP_ENTRIES, CZ_RULE_FOLDERS — rule-folder and node records checked by the rule-folder lock functions.
• FND_APPLICATION, FND_FORM_FUNCTIONS, FND_COMPILED_MENU_FUNCTIONS, FND_GRANTS — EBS foundation tables used to validate application, responsibility, and privilege context.

Usage Notes

CZ_SECURITY_PVT is invoked indirectly by CZ-based forms and concurrent programs rather than called directly by end users. Developers extending Configurator or CZ authoring screens typically reach this package through sibling CZ APIs, and it is referenced by eight other packages. Because it is classified as a private (PVT) package, direct invocation from custom code is discouraged; integrations should use supported CZ public APIs. Where direct calls are unavoidable — for example, to test IS_UI_DEF_LOCKED before programmatic modification of a UI definition — callers must supply a valid cz_ui_def_id or model identifier and must be prepared to handle the named exceptions raised on privilege or lock failures.