Search Results hr_security_internal




Overview
Explore in AI Chat

Overview

HR_SECURITY_INTERNAL is a core Oracle E-Business Suite PL/SQL package body owned by the APPS schema that implements the low-level engine for Oracle Human Resources (HRMS) security. Its primary business function is to evaluate, cache, and apply row-level access rules that determine which people, assignments, organizations, positions, and payrolls a given application user is permitted to see or transact upon. Rather than exposing a user-facing API, it operates beneath Oracle HRMS security profiles, the Security Profile setup forms, and the person/organization/position/payroll list generation routines. The package replaces and extends the functionality traditionally associated with HR_SECURITY by providing internal helper routines for maintaining the various security list tables (PER_PERSON_LIST, PER_ASSIGNMENT_LIST, PER_ORGANIZATION_LIST, PER_POSITION_LIST) and the change-tracking tables that support incremental refresh of those lists. It is classified as an OTHER API in the ETRM metadata and is documented as VALID in both 12.1.1 and 12.2.2. The package depends heavily on other HRMS utility packages including HR_SECURITY, HR_GENERAL, HR_GENERAL2, HR_API, and HR_UTILITY, and it is referenced by twenty-four other database objects, confirming its role as a foundational security service rather than a standalone utility.

Key Procedures and Functions

The package exposes thirty-six documented procedures and functions. The list-maintenance routines manipulate the cached security lists: POPULATE_NEW_PERSON, POPULATE_NEW_CONTACT, and POPULATE_NEW_PAYROLL insert newly created person, contact, and payroll records into the appropriate list tables; ADD_TO_PERSON_LIST and CLEAR_FROM_PERSON_LIST manage membership in PER_PERSON_LIST; and CLEAR_FROM_PERSON_LIST_CHANGES, RE_ENTER_PERSON_LIST_CHANGES, and COPY_TO_PERSON_LIST_CHANGES operate on the PER_PERSON_LIST_CHANGES tracking table to reconcile incremental security changes. GRANT_ACCESS_TO_PERSON and REVOKE_ACCESS_FROM_PERSON apply or remove explicit user access to a person record. The access-testing family — ORG_ACCESS_KNOWN, POS_ACCESS_KNOWN, PAY_ACCESS_KNOWN, and PER_ACCESS_KNOWN — returns a boolean/indicator as to whether the current user has access to a given organization, position, payroll, or person. The SHOW_* procedures (SHOW_ORGANIZATION, SHOW_POSITION, SHOW_PAYROLL) present access information via FND_MESSAGE, supporting diagnostic and setup validation. GET_ASSIGNMENTS retrieves assignment rows subject to security. OP is an internal operation dispatcher, and EVALUATE_CUSTOM supports evaluation of custom security criteria.

Tables Accessed

Through APPS synonyms the package reads and writes the principal HRMS and security tables. Person and assignment data is drawn from PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F, PER_ASSIGNMENTS_F, PER_PERIODS_OF_SERVICE, PER_PERSON_TYPES, and PER_PERSON_TYPE_USAGES_F. Security definitions and cached results are held in PER_SECURITY_PROFILES, PER_SECURITY_ORGANIZATIONS, PER_SECURITY_USERS, PER_PERSON_LIST, PER_PERSON_LIST_CHANGES, PER_ASSIGNMENT_LIST, PER_ORGANIZATION_LIST, and PER_POSITION_LIST. Organization and structure information comes from HR_ALL_ORGANIZATION_UNITS, PER_ORG_STRUCTURE_ELEMENTS, and PER_ORG_STRUCTURE_VERSIONS, while position information is sourced from HR_ALL_POSITIONS_F, PER_POSITION_LIST, and PER_POS_STRUCTURE_ELEMENTS. Payroll security relies on PAY_ALL_PAYROLLS_F, PAY_PAYROLLS_F, PAY_PAYROLL_LIST, and PAY_SECURITY_PAYROLLS. FND_USER and PER_APPLICATIONS supply user and application context, and the package also references IRC_REC_TEAM_MEMBERS for recruiting team membership. The PLITBLM package supports PL/SQL character table operations, and DUAL serves as the standard single-row source.

Usage Notes

HR_SECURITY_INTERNAL is not intended for direct invocation by end users or customers. It is invoked internally by Oracle HRMS security framework code, by Oracle Forms such as the Security Profile and Person/Assignment maintenance forms, by concurrent programs that rebuild or incrementally refresh security lists, and by the HR_SECURITY package upon which the higher-level security APIs are built. Site-specific customizations should call the documented public security APIs (typically HR_SECURITY) rather than this internal package, though advanced integrators may reference EVALUATE_CUSTOM, GET_ASSIGNMENTS, and the *_ACCESS_KNOWN functions when embedding security filtering into custom reports or extensions. Because the package is undocumented as a customer-facing API and its behavior is tightly coupled to the security list tables, direct modification is discouraged. The presence of the *_CHANGES routines indicates that it participates in the incremental security cache refresh cycle and should be treated as a supported internal dependency when troubleshooting discrepancies between a user's expected and actual HRMS visibility.