Search Results has_updateopportunityaccess

Overview

AST_ACCESS is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite and classified under the ETRM API taxonomy as OTHER. It is a component of the Oracle Sales (Sales Foundation) application family, whose database objects conventionally carry the AST prefix. The package encapsulates access-control logic for sales leads and opportunities: it determines whether a given user or resource is authorized to create, update, own, or otherwise manipulate a specific lead or opportunity record. By centralizing these checks in a single package, Oracle Sales ensures that security rules and administrative overrides are applied consistently across every entry point that touches lead and opportunity data.

The package specification is declared with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges of the invoking user rather than the definer. It also declares a package-level record variable, G_Access_Rec_Type, typed as AS_ACCESS_PUB.ACCESS_PROFILE_REC_TYPE and initialized from AS_API_RECORDS_PKG.GET_P_ACCESS_PROFILE_REC. This indicates a shared access-profile structure, populated by the Initialize procedure and reused by the individual access-check routines.

Key Procedures and Functions

The ETRM metadata documents five procedures in the package specification:

• Initialize — Initializes the package-level state, in particular the G_Access_Rec_Type access-profile record, so that subsequent access checks operate against a correctly populated profile.
• Has_Create_LeadOppAccess — Determines whether the caller has privileges to create a lead or opportunity, taking an administrative flag and an opportunity/lead identifier as inputs and returning the standard EBS return status, message count, and message data outputs.
• Has_UpdateLeadAccess — Evaluates whether the supplied sales lead may be updated by the identified user, considering the administrative flag, administrative group, person, and resource identifiers.
• Has_LeadOwnerAccess — Establishes whether the identified user or resource qualifies as the owner of the specified sales lead, a distinct ownership-based check used for owner-level operations.
• Has_UpdateOpportunityAccess — Performs the equivalent update authorization check at the opportunity level, keyed on the lead identifier and the caller's administrative, group, person, and resource context.

All access-check procedures follow the standard Oracle EBS API convention of returning x_return_status, x_msg_count, and x_msg_data, allowing callers to inspect both the outcome and any diagnostic messages.

Tables Accessed

The ETRM metadata for this object does not enumerate any tables referenced through APPS synonyms. In practice, access decisions of this kind are driven from the Oracle Sales lead and opportunity tables and the resource and administrative group definitions that establish ownership and team membership. Because the documented metadata lists no table references, implementations should treat the underlying queries as internal to the package and rely solely on the documented procedure interfaces rather than direct table access.

Usage Notes

AST_ACCESS is an internal, server-side utility rather than a public integration API. It is referenced by three other packages within the EBS code base, which indicates that lead and opportunity maintenance logic routes its authorization questions through these procedures before permitting a create or update operation. Typical invocation therefore occurs from Oracle Sales forms, from the business logic layered behind those forms, and from other PL/SQL packages performing lead or opportunity maintenance.

Customizations that need to reproduce standard lead or opportunity security behavior should call these procedures rather than reimplementing the rules, and should handle the standard return status and message outputs. Because the package runs with AUTHID CURRENT_USER, callers require appropriate privileges on the underlying objects. The package is marked noship in its version header, underscoring that it is an internal implementation artifact intended for use within the Oracle Sales application rather than for external or customer-facing interfaces.