Search Results view_labor_costs_new

Overview

PA_SECURITY is the central project security enforcement package in Oracle Projects. It answers the fundamental authorization question that every Projects form, report, and API must resolve before displaying or modifying data: is the current user permitted to query or update a given project, and is that user entitled to see labor cost information on that project? The package is owned by APPS and classified as OTHER in the ETRM 12.2.2 metadata, indicating it is an internal infrastructure package rather than a public, supported API.

PA_SECURITY maintains a session-level security context in a set of global PL/SQL variables, including G_user_id, G_person_id, G_module_name, G_query_allowed, G_update_allowed, G_view_labor_costs, G_cross_project_user, and G_cross_project_view. Applications establish this context once per session by calling Initialize, then issue repeated authorization checks against individual projects. This design avoids re-evaluating role and grant hierarchies for every row rendered or processed.

Key Procedures and Functions

The documented interface comprises eleven procedures and functions:

• INITIALIZE — Populates the package globals for a given user and calling module. It is the mandatory entry point; all other functions depend on the context it establishes.
• VIEW_LABOR_COSTS — Determines whether the current user may view labor costs for a specified project. The user's search term, "view_labor_costs," corresponds directly to this function, which is also mirrored in the G_view_labor_costs global.
• VIEW_LABOR_COSTS_NEW and VIEW_LABOR_COSTS_NEW2 — Successive revisions of the labor cost visibility check, retained for backward compatibility as the security model evolved.
• ALLOW_QUERY — Returns whether the current user may query a specified project.
• ALLOW_UPDATE — Returns whether the current user may update a specified project.
• SET_VALUE — Overrides a named security level global with a supplied value, used principally for testing and administrative adjustment of session context.
• CHECK_KEY_MEMBER — Validates that a person is a key member of a project, date-effectively.
• CHECK_KEY_MEMBER_NO_DATES — The date-independent variant of the key member check.
• CHECK_LABOR_COST_ACCESS — Evaluates labor cost access for a person/project pair independent of the initialized session, supporting cross-user security evaluation.
• CHECK_PROJECT_AUTHORITY — Confirms that a person holds authority over a project; this is the only documented function bearing a TRUST pragma, permitting calls to subordinate functions such as pa_security_pvt.get_grantee_key that lack their own pragmas.

All other functions carry RESTRICT_REFERENCES pragmas for WNDS and WNPS, making them safe for use inside SQL statements — a critical property for Projects views and reports that filter rows through security predicates.

Tables Accessed

PA_SECURITY reads the following tables through APPS synonyms:

• FND_GRANTS — Stores the grants assigned to users and responsibilities that define project authority.
• FND_OBJECTS — Resolves the object identifiers referenced by those grants.
• PA_PROJECTS_ALL — The project master, supplying project attributes required for authority evaluation.
• PA_PROJECT_ROLE_TYPES_B — Defines project role types, including key member designations.
• PA_ROLE_CONTROLS — Maps role types to the security controls and access levels they confer, forming the bridge between role assignment and query, update, or labor cost privileges.

Usage Notes

PA_SECURITY is referenced by 110 other packages, making it one of the most widely depended-upon units in Oracle Projects. It is invoked from Projects forms, concurrent programs, and reporting views whenever project-level authorization or labor cost visibility must be determined. Because the package caches session context in globals, callers must invoke Initialize at the start of each session or request, supplying the user identifier and calling module; failing to do so leaves checks evaluating against stale or unset state. Custom code should treat these routines as internal infrastructure, call Initialize once, and then use the allow_query, allow_update, view_labor_costs, and check_project_authority results as predicates rather than querying the underlying grant and role tables directly, so that all security rule changes — including the New and New2 labor cost variants — are automatically honored.