Search Results jtf_um_role_verification




Overview
Explore in AI Chat

Overview

JTF_UM_ROLE_VERIFICATION is an Oracle Applications (APPS) PL/SQL package that belongs to the User Management (UM) infrastructure of Oracle E-Business Suite. Its declared purpose, as stated in the package header comments, is to verify whether a given role exists in User Management and, where appropriate, to update the associated principal identifier. The package is defined with AUTHID CURRENT_USER, meaning that its unqualified database object references resolve against the privileges of the invoking schema rather than the owner of the package. In practice, this design allows the calling application or administrative routine to exercise its own access rights when the verification logic executes.

The package addresses a specific administrative concern within the Oracle User Management model: maintaining referential consistency between roles represented as authorization principals and the various UM entities—such as subscriptions, subscription roles, usertypes, and usertype roles—that may reference those principals. Its dual responsibilities are therefore validation (confirming existence or usage) and reconciliation (repointing stale principal identifiers to newly generated ones). The package originates from an early UM release, as reflected in its original header revision from November 2002, and retains a compact public interface consisting of two procedures.

Key Procedures and Functions

The documented interface exposes two procedures. No public functions are declared in the package specification.

  • UPDATE_AUTH_PRINCIPAL_ID — Classified in the source comments as a private procedure. Its purpose is to update existing User Management records that currently reference an old authorization principal identifier, replacing that value with a new authorization principal identifier. It accepts the old and new principal IDs as input and performs the corresponding data correction. This procedure supports scenarios in which a principal has been recreated or re-identified and dependent UM rows must be kept aligned with the current principal.
  • IS_AUTH_PRINCIPAL_REFERRED — Classified as a private procedure. It checks for the existence of a supplied authorization principal (by name or identifier) across the UM tables. If the principal is referenced anywhere in the usertype or enrollment structures, the procedure returns a status of "E" together with an appropriate message indicating that the role cannot be deleted. If no reference is found, it returns "S" in the return status parameter. Error conditions, such as the principal existing in UM, are communicated through the standard message stack parameters.

Tables Accessed

The package operates against the core User Management principal and role tables, accessed through APPS synonyms. The documented tables are:

  • JTF_AUTH_PRINCIPALS_B — The base table holding authorization principal definitions, including the principal identifiers manipulated by UPDATE_AUTH_PRINCIPAL_ID and validated by IS_AUTH_PRINCIPAL_REFERRED.
  • JTF_UM_SUBSCRIPTIONS_B — Stores subscription definitions that may reference a principal; consulted to determine whether a role is in use.
  • JTF_UM_SUBSCRIPTION_ROLE — Associates subscriptions with roles, forming part of the reference chain checked during verification.
  • JTF_UM_USERTYPES_B — Holds usertype definitions that can be tied to principals and roles.
  • JTF_UM_USERTYPE_ROLE — Maps usertypes to roles, a further location examined when determining whether a principal is still referenced.

Usage Notes

JTF_UM_ROLE_VERIFICATION is an internal UM utility rather than a general-purpose public API. Because its procedures are marked private and are not intended for direct customer invocation, it is typically called by other UM packages and administrative flows—the ETRM metadata indicates it is referenced by one other package. Invocation occurs during role deletion or principal maintenance processing, when the system must confirm that a role is not in active use before permitting removal, or when principal identifiers must be reconciled across dependent records. It is not a standalone concurrent program and is not exposed through a standard Oracle Forms interface for end users. Customizations and extensions should avoid calling these private procedures directly, since signatures and behavior may change across releases; instead, they should rely on the supported User Management APIs that internally invoke this verification logic.