Search Results check_row_viewable




Overview
Explore in AI Chat

Overview

HZ_UI_UTIL_PKG is a server-side PL/SQL utility package in the Oracle E-Business Suite Trading Community Architecture (TCA) / Oracle Customer Hub (HZ) schema. Its purpose is to centralize the user-interface level security and visibility decisions that TCA maintenance forms and self-service pages require before they render or persist party-related data. Rather than embedding privilege checks in individual forms, the package exposes a small, uniform API that answers three questions for any given TCA entity: can the current user create instances, can the user see a specific row, and can the user modify or delete a specific row. The package header advertises it as a UI utility, and the body ($Header: ARHPUISB.pls 120.19) confirms it draws heavily on the Third Party Data Integration and data-matching framework (HZ_MIXNM_UTILITY) to resolve entity-attribute-level privileges. In Oracle EBS 12.1.1 and 12.2.2 the package is classified as API classification OTHER, meaning Oracle does not publish it as a supported public API, though it remains callable from custom code and is referenced by one other documented package.

Key Procedures and Functions

  • CHECK_ENTITY_CREATION — Determines whether the current user may create instances of a named entity. It short-circuits to an affirmative flag for HZ_ORGANIZATION_PROFILES and HZ_PERSON_PROFILES, and otherwise delegates to HZ_MIXNM_UTILITY.CheckUserCreationPrivilege. It returns an OUT create flag of 'Y' or 'N', defaulting to 'N' on any unexpected error.
  • GET_VIEW_PREDICATE — Returns a SQL predicate fragment used to filter a query so that only rows the user is permitted to view are returned. It accepts an entity/table name, an optional table alias for the SELECT, and an FND function name. Documented behavior shows special handling for HZ_PARTIES.
  • CHECK_ROW_ACCESS — Evaluates whether the current user has general access rights to a specific row of a TCA entity.
  • CHECK_ROW_VIEWABLE — Reports whether a specific row may be viewed by the current user.
  • CHECK_ROW_UPDATEABLE — Reports whether a specific row may be updated by the current user.
  • CHECK_ROW_DELETEABLE — Reports whether a specific row may be deleted by the current user. This is the routine most commonly targeted when developers or form personalizations need to suppress the delete action on a TCA record, such as a customer account, party site, or relationship.
  • CHECK_COLUMNS — Applies column-level privilege evaluation for the entity in question, complementing the row-level checks above.
  • GET_VALUE — A general-purpose lookup helper that retrieves a stored value for the entity under evaluation.

Tables Accessed

The package resolves privileges against the core TCA party model tables exposed through APPS synonyms: HZ_PARTIES (the master party record), HZ_CUST_ACCOUNTS (customer accounts), HZ_CUST_ACCT_SITES_ALL (account site usages), HZ_PARTY_SITES (party site definitions), and HZ_RELATIONSHIPS (party-to-party relationships such as contact or account roles). These tables supply the entity keys and attribute values evaluated by the row- and column-level checks. PLITBLM is also referenced; it is the PL/SQL integer table type used for passing collections of identifiers between the utility and its callers, supporting set-based privilege evaluation rather than row-by-row lookups.

Usage Notes

HZ_UI_UTIL_PKG is invoked from the TCA maintenance forms and self-service UI layers during query, insert, update, and delete operations to enforce data-level security without duplicating logic in each form. Typical call points include CHECK_ENTITY_CREATION when a user opens a creation flow, GET_VIEW_PREDICATE when a block query is constructed so unauthorized rows are silently excluded, and CHECK_ROW_DELETEABLE before a delete is committed. Because the package is classified as OTHER and Oracle does not document its signatures as public interfaces, customizations should treat the API as subject to change between point releases; extensions that must survive patching should wrap or replicate the check rather than depend on exact behavior. Developers searching for "check_row_deleteable" are generally looking to gate or suppress the delete action on a TCA entity, and the routine is the appropriate hook for that purpose in both 12.1.1 and 12.2.2.