Search Results get_batch_security_clause




Overview
Explore in AI Chat

Overview

GL_ACCESS_SET_SECURITY_PKG is a server-side PL/SQL package owned by the APPS schema that centralizes access set security enforcement for Oracle General Ledger and the applications that publish or consume GL data. Access sets define which ledgers, and within those ledgers which balancing segment values, a responsibility may use. Rather than requiring every inquiry form, report, and concurrent program to re-implement its own validation logic, this package exposes a small set of reusable routines that translate an access set definition into a SQL predicate (a "security clause") or into a direct access decision. The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling session and is intended to be called from within an APPS runtime context rather than executed directly by end users.

The header dates to the 11i era (created 2001 by T. Cheng) and the package remains present and supported in EBS 12.1.1 and 12.2.2, where it is referenced by dozens of other application packages. Its primary role is therefore infrastructural: it is the single source of truth for "can this responsibility see this journal, this batch, this ledger?"

Key Procedures and Functions

  • GET_SECURITY_CLAUSE — Builds the security clause portion of a WHERE clause for ledger and, optionally, segment value validation. It supports three ledger check modes (no ledger information, a ledger ID passed in directly, or the name of the column that holds the ledger ID) and two segment value modes (no segment validation, or segment value checking). The access privilege passed in determines the required access level: full, write, or read-only. Full access is only valid in combination with column-based ledger checking and no segment validation. If the caller supplies an invalid combination, the package raises the INVALID_PARAM exception.
  • GET_JOURNAL_SECURITY_CLAUSE — Returns a security predicate restricted to journal entries in GL_JE_HEADERS, allowing journal inquiry and reporting to be filtered by the caller's access set privileges.
  • GET_BATCH_SECURITY_CLAUSE — The routine most commonly searched for. It produces the batch-level equivalent of the journal security clause, so that journal batch inquiry, posting, and similar batch-oriented screens return only the batches the responsibility is entitled to see. It follows the same pattern as the journal variant, deriving its predicate from the access set definition rather than from hard-coded values.
  • GET_JOURNAL_ACCESS — Evaluates a specific journal against the caller's access set and returns the resulting access level, rather than returning a SQL fragment. This is the row-level check used when a single record must be adjudicated rather than a result set filtered.
  • GET_DEFAULT_LEDGER_ID — Returns the ledger the session should default to, based on the access set assignments in effect.
  • GET_ACCESS — The general-purpose access level lookup that underlies the more specialized routines, returning the privilege the caller holds for a given access set context.

Tables Accessed

The package reads access set definitions from GL_ACCESS_SETS and the mapping of responsibilities and users to those sets from GL_ACCESS_SET_ASSIGNMENTS. Ledger attributes, needed to interpret ledger IDs and to select a default ledger, come from GL_LEDGERS. When journal and batch clauses are constructed, the target of the predicate is GL_JE_HEADERS, which supplies the ledger and batch columns the clause is applied against. DUAL is used for simple single-row evaluations such as retrieving the default ledger ID.

Usage Notes

Typical callers are journal entry and journal inquiry forms, batch posting programs, standard GL reports, and the many other modules that display or process GL journals. Because the package is referenced by more than thirty other application packages, customizations should never reimplement access set logic; they should call these routines so that changes to access set definitions are honoured consistently. In custom code the usual pattern is to concatenate the clause returned by GET_BATCH_SECURITY_CLAUSE or GET_JOURNAL_SECURITY_CLAUSE onto the base query, or to test GET_JOURNAL_ACCESS for a single row before allowing an action. All calls must occur in an APPS session where the correct responsibility context and access set assignments are already established.