Search Results igw_security




Overview
Explore in AI Chat

Overview

IGW_SECURITY is the central authorization engine for Oracle Grants Management (formerly Grants Proposal, IGW) within Oracle E-Business Suite. The package body implements the runtime security logic that governs who may view, create, or modify proposal records held in the grants schema. Rather than embedding access rules in individual forms or reports, the application routes authorization decisions through this single PL/SQL package, which evaluates the current user's privileges against the role and rights configuration stored in the IGW tables.

In Oracle EBS 12.1.1 and 12.2.2 the object resides in the APPS schema and is reported with status VALID. The ETRM metadata classifies the API as OTHER, indicating that it is a supporting internal package rather than a public, documented extension interface. It is a read-oriented access-control package that depends on FND_PROFILE for session and profile-option context and on GMS_INSTALL to determine whether the Grants Management product is installed and licensed in the current environment.

Key Procedures and Functions

The documented package exposes four entry points:

  • ALLOW_QUERY — Determines whether the current user is permitted to retrieve or display a given proposal record. This is the read-side check invoked when a user attempts to open or list proposals.
  • ALLOW_CREATE — Evaluates whether the current user may create a new proposal. Used to enable or suppress creation actions in the user interface and to validate inserts at runtime.
  • ALLOW_MODIFY — Determines whether the current user may update an existing proposal. This governs edit actions for records the user can already see.
  • GMS_ENABLED — Reports whether the Grants Management (GMS) application is installed and active. Callers use this to avoid executing grants-specific security logic in environments where the product is not deployed.

Each of the three authorization functions returns a Boolean-style result that the calling form, concurrent program, or API uses to permit or deny the requested operation. No parameter lists are documented in the ETRM metadata and therefore none are asserted here.

Tables Accessed

The package body references three application tables through APPS synonyms:

  • IGW_PROPOSALS_ALL — The base proposal table. Security checks resolve the proposal under consideration and its owning attributes against this table.
  • IGW_PROP_USER_ROLES — Maps users to the proposal roles they hold, forming the basis for individual-level access decisions.
  • IGW_ROLE_RIGHTS — Defines the privileges (query, create, modify) granted to each role, supplying the right-side of the authorization evaluation.

In addition, the dependency listing shows references to FND_PROFILE (profile-option values), GMS_INSTALL (installation status), IGW_SECURITY itself (recursive or helper calls), and the SYS STANDARD package. The metadata states that IGW_SECURITY is not referenced by any database object, while separate ETRM data records that it is referenced by 10 other packages, confirming it is consumed widely by sibling grants packages rather than by stored schema objects such as triggers or views.

Usage Notes

IGW_SECURITY is an internal package and is not intended as a public extension API. It is invoked indirectly whenever a user opens a Grants Management form, runs a proposal-related concurrent program, or calls a grants API that performs its own authorization check. Because the package is not referenced by database objects, all invocation originates from the middle tier — primarily Oracle Forms and the PL/SQL APIs of related grants packages.

Custom code that reads or writes proposal data outside the standard Grants forms should call the same ALLOW_QUERY, ALLOW_CREATE, and ALLOW_MODIFY checks to remain consistent with delivered security rules. GMS_ENABLED should be tested first so that grants-specific logic is skipped gracefully where the product is not installed. Because the package depends on FND_PROFILE, it relies on a correctly initialized EBS session; callers outside a form or concurrent-manager context must ensure the FND session is established before invoking these routines. Direct modification of this package is unsupported and would be overwritten during patching or upgrade.