Search Results pa_security




Overview
Explore in AI Chat

Overview

PA_SECURITY is a foundational Oracle Projects package body owned by the APPS schema that centralizes row-level and function-level security enforcement for project and labor cost data. Its core responsibility is to determine whether a given application user is authorized to query or modify a project, a task, or the labor costs posted against them. The package bridges Oracle Projects with the native EBS security infrastructure by combining Oracle Application Object Library (FND) grant and object definitions with the Projects-specific project player and role control model. Because PA_SECURITY is referenced by more than 110 other database objects, it functions as the standard access-control gateway that most Oracle Projects and external-facing APIs call before exposing or altering secured data. The package body is documented as VALID in both 12.1.1 and 12.2.2, confirming a stable interface across those releases.

Key Procedures and Functions

  • INITIALIZE — Establishes the package-level session state, typically loading the current user's identity and profile-driven security context for subsequent calls within the same session.
  • ALLOW_QUERY — Evaluates whether the current user may view a given project or secured entity, forming the read-side authorization check used by query-based screens and reports.
  • ALLOW_UPDATE — Returns the corresponding write-side authorization decision, determining whether the user may modify a project or associated record.
  • VIEW_LABOR_COSTS, VIEW_LABOR_COSTS_NEW, VIEW_LABOR_COSTS_NEW2 — A progression of checks governing whether a user is permitted to see labor cost amounts, which Oracle Projects secures separately from general project visibility. The NEW and NEW2 variants represent successive enhancements to this logic.
  • CHECK_LABOR_COST_ACCESS — A dedicated gatekeeper applying the labor cost visibility rules to a specific context.
  • CHECK_PROJECT_AUTHORITY — Determines the user's authority level over a project, mapping project players and role assignments to a permissible action.
  • CHECK_KEY_MEMBER and CHECK_KEY_MEMBER_NO_DATES — Validate the user's membership in the relevant key member or project player set. The _NO_DATES variant performs the check without applying date-range validity, useful for historical or override evaluations.
  • SET_VALUE — Assigns a value to an internal package variable, supporting the stateful configuration used by the checks above.

Tables Accessed

PA_SECURITY reads FND_GRANTS and FND_OBJECTS to resolve grants and permission sets defined through the AOL security model, and FND_PROFILE for profile-option-driven behavior. Project-level context is derived from PA_PROJECTS_ALL, the base project table, and from PA_PROJECT_PLAYERS and PA_PROJECT_ROLE_TYPES_B, which map users to projects through role assignments. PA_ROLE_CONTROLS provides the configurable rules that translate those roles into query and update privileges. The package also depends on PA_SECURITY_PVT, PA_SECURITY_EXTN, and PA_UTILS for shared logic and extensions.

Usage Notes

PA_SECURITY is invoked indirectly rather than directly by end users. Oracle Projects forms, concurrent programs, and reporting logic call it to enforce security before displaying or updating data, and its wide dependency footprint means custom extensions and external integrations should route authorization checks through the same package to remain consistent with standard behavior. The PA_SECURITY_EXTN dependency indicates that customer-defined security extensions are supported and are layered into these decisions. Because the package depends on session-level profile and user context, INITIALIZE (or an equivalent context-setup call) should precede any authorization check in custom code. Oracle does not document this object as a public API, so direct calls should be avoided in favor of the supported Project APIs that already incorporate these checks.