Search Results delete_prop_user

Overview

IGW_PROP_USERS_PVT is a private (PVT) PL/SQL API package in the Oracle E-Business Suite APPS schema that manages the association between proposals and the users who participate in them. Proposals are the core business objects of Oracle Grants Management and the broader IGW (Grants/Proposals) product family, and each proposal must have one or more designated users who can view, edit, or otherwise act upon it. This package encapsulates the insert, update, and delete logic for those proposal-user relationships, insulating callers from the underlying table structures while enforcing validation, record versioning checks, and the standard EBS API error-handling contract (x_return_status, x_msg_count, x_msg_data).

The "_PVT" classification indicates that the package forms part of an internal API layer. It is not intended as a public integration interface; rather, it is invoked by the public wrapper packages and by the Oracle Forms user interface that manages proposals. Its declaration uses AUTHID CURRENT_USER, so privileges are evaluated against the calling user rather than the package owner, which is consistent with standard EBS API practice.

Key Procedures and Functions

• CREATE_PROP_USER — Inserts a new proposal-user assignment. It accepts the initialization, commit, and validate-only flags common to FND_API-style APIs, proposal identifying information (ID and number), user identifying information (ID, username, full name), the active date range, and a logged user ID, and returns the new row identifier along with the standard return status, message count, and message data outputs.
• UPDATE_PROP_USER — Modifies an existing proposal-user record. In addition to the parameters used at creation, it requires the rowid and a record version number to support optimistic locking, ensuring that concurrent modifications do not silently overwrite one another.
• DELETE_PROP_USER — Removes a proposal-user assignment. It takes the rowid and record version number (plus the standard control flags and logged user ID) to identify and safely delete the target row.
• CHECK_IF_USER_HAS_SEEDED_ROLE — A validation helper that determines whether a given user holds a seeded (Oracle-delivered) role. This supports business rules that treat certain role assignments differently from user-created ones, for example restricting removal of users whose roles were provisioned by Oracle.
• CHECK_LOCK_GET_COLS — A concurrency and retrieval helper. It verifies locking state and fetches the column values needed before an update or delete proceeds, forming part of the optimistic-locking mechanism referenced by the record version number parameters.
• CHECK_ERRORS — Centralizes error inspection, translating captured messages into the API return status and message stack so that callers receive consistent diagnostics.

Tables Accessed

• IGW_PROP_USERS — The primary table, storing the proposal-to-user assignments. The create, update, and delete procedures operate directly against this table.
• IGW_PROP_USER_ROLES — Holds the roles associated with a proposal user. It is consulted and potentially maintained in conjunction with user assignment changes, particularly in the seeded-role check.
• IGW_ROLES — The role definition table, referenced to resolve and validate the roles held by a proposal user.

Usage Notes

Because IGW_PROP_USERS_PVT is a private package and is referenced by no other documented packages, it is typically called from the Oracle Forms screens for proposal maintenance, where the form triggers invoke the create, update, and delete procedures as the user adds or removes personnel from a proposal. It may also be invoked by custom extensions or by higher-level public APIs within the same product family. Callers must observe the standard FND_API conventions: check x_return_status after every call, inspect x_msg_count and x_msg_data when errors occur, and pass the correct record version number on update and delete to satisfy optimistic-locking requirements. Direct invocation from external integrations should be avoided in favor of supported public APIs, since the private interface and its parameter signatures may change between releases.