Search Results exist_orghvrsn_for_security




Overview
Explore in AI Chat

Overview

APPS.HRI_OLTP_VIEW_SECURITY is a thin wrapper package within the Oracle E-Business Suite HR Intelligence (HRMS Intelligence / Daily Business Intelligence) schema. Its sole responsibility is to expose organization-structure security validation logic to the OLTP view layer. The package body examined here reflects the 12.1.1 / 12.2.2 code line, identified by the header revision hriovsec.pkb 120.2 shipped in November 2011.

In the HR Intelligence architecture, security functions must be callable from Oracle Forms, concurrent programs, and the materialized views that populate the DBI dashboards. Rather than allowing those callers to invoke the business-process layer directly, Oracle interposes this security-facing package so that all view-layer consumers use a single, controlled entry point. Each subroutine delegates immediately to the corresponding function in the business process layer package HRI_BPL_ORG, which performs the actual validation. This pattern keeps the OLTP view package free of business logic while preserving a stable, documented API surface.

The functional purpose is to answer, for a given organization-structure definition, whether the current user is permitted to see that structure under the HRMS security profile. The package is therefore a gatekeeper: its return value determines whether organization hierarchy data will be visible in HR Intelligence reports and dashboards.

Key Procedures and Functions

  • EXIST_ORGHVRSN_FOR_SECURITY — Determines whether a specific organization structure version is accessible to the current user under the applicable security profile. It accepts an organization structure version identifier and returns a character value. The body simply forwards the request to HRI_BPL_ORG.EXIST_ORGHVRSN_FOR_SECURITY. This variant is used when the caller is resolving access at the version level, where a structure may have multiple effective-dated versions.
  • EXIST_ORGH_FOR_SECURITY — Determines whether an organization structure, identified at the structure level rather than the version level, is accessible to the current user. It accepts an organization structure identifier and returns a character value, delegating to HRI_BPL_ORG.EXIST_ORGH_FOR_SECURITY. This is the function most commonly referenced in security predicates on organization hierarchy views, and it is the target of the search term exist_orgh_for_security.

Both functions are read-only; they neither raise application exceptions nor commit, instead returning a status value that the caller interprets.

Tables Accessed

The documented table reference for this package is PER_ORG_STRUCTURE_VERSIONS, accessed through an APPS synonym. The package body does not issue SQL against this table directly — the data types of the incoming parameters are anchored to its columns via %TYPE declarations. This anchoring guarantees that the wrapper's signatures remain synchronized with the underlying Organization Structures schema should column definitions change. The actual querying of organization structures and their versions, and the comparison against the user's security profile, takes place in HRI_BPL_ORG, which resolves the HRMS security model over the PER_ORG_STRUCTURE_VERSIONS data.

Usage Notes

HRI_OLTP_VIEW_SECURITY is classified as API type OTHER in the ETRM metadata and is referenced by three other packages, all of which rely on its security predicates for organization hierarchy visibility. Typical invocation paths include:

  • Organization hierarchy views and materialized views in the HR Intelligence schema, which embed calls to EXIST_ORGH_FOR_SECURITY in their WHERE clauses to constrain rows to structures the user may see.
  • Concurrent programs that refresh HR Intelligence collections and must apply the same security filter when staging data.
  • Custom code and extensions that need to reproduce the standard DBI security behavior without calling the business-process layer directly.

Because the package is version-controlled at revision 120.2 and unchanged across the 12.1.1 and 12.2.2 releases, customizations should treat the signatures as stable. Callers should not expect the functions to return a Boolean; the VARCHAR2 result follows the HR Intelligence convention of using 'Y'/'N' semantics interpreted by the invoking view or program.