Search Results gms_enabled

Overview

IGW_SECURITY is a PL/SQL security package owned by the APPS schema and classified as an OTHER API in the ETRM repository. It is part of the Oracle Grants Management/IGW (Internet Grants Warehouse) family of packages and is compiled with AUTHID CURRENT_USER, meaning that its unqualified references are resolved in the privilege domain of the invoking user rather than the defining user. The package centralizes the authorization checks that govern whether a given user may create, modify, or query a proposal through the IGW self-service applications. Rather than embedding security logic in every screen or region, the application layer calls a small, stable set of boolean-style functions that return a VARCHAR2 verdict based on the function name being invoked, the proposal in question, and the user performing the action. The header comment (igwcoses.pls 115.6, dated 2002) indicates the package has been stable since the early 11i code line and was carried forward largely unchanged into EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

• ALLOW_CREATE — Determines whether a user is permitted to create a proposal for the specified function. Returns a VARCHAR2 result used as a gate by the calling application.
• ALLOW_MODIFY — The function most often referenced in customizations and searches. It evaluates whether the given user may modify the identified proposal for the named function, returning a VARCHAR2 authorization verdict. This is the entry point custom code typically calls when it needs to enforce the same edit rights as the standard IGW forms.
• ALLOW_QUERY — Evaluates read access, determining whether the user may query or view the specified proposal.
• GMS_ENABLED — Returns a VARCHAR2 flag indicating whether the Grants Management (GMS) subsystem is enabled, allowing callers to branch their security behavior accordingly.

All three allow functions share the same conceptual signature: a function name, a proposal identifier, and a user identifier. Each is decorated with pragma restrict_references(..., wnds, wnps), guaranteeing that the functions write no database state and package state, which makes them safe for use inside SQL statements and views subject to purity rules.

Tables Accessed

The package resolves its authorization data through three APPS synonyms:

• IGW_PROPOSALS_ALL — The core proposal entity, supplying proposal context such as ownership and status that feeds the access decision.
• IGW_PROP_USER_ROLES — Maps users to roles in the context of a proposal, providing the per-proposal role assignment used to determine whether a user is a participant.
• IGW_ROLE_RIGHTS — Defines the rights (create, modify, query) granted to each role, completing the role-to-privilege linkage that the allow functions evaluate.

Because the package is AUTHID CURRENT_USER and contains only query-style functions, these tables are read but not written by IGW_SECURITY itself.

Usage Notes

IGW_SECURITY is invoked at runtime by the IGW self-service forms, JSP regions, and OA Framework pages as a security filter before rendering or committing proposal data. ETRM records that it is referenced by ten other packages, which confirms its role as a shared authorization utility across the grants module. When developing custom extensions, the supported pattern is to call ALLOW_MODIFY (or its sibling functions) rather than reimplementing the role-rights logic; the caller passes the function name, proposal ID, and user ID and inspects the returned VARCHAR2 verdict. The restrict_references pragmas mean the functions can safely be called from SQL, for example inside a view or a WHERE clause. Because the return value is a string rather than a boolean, callers typically compare against the application's convention for an affirmative result.