Search Results assign_responsibility

Overview

The APPS.CCT_RESOURCE_ASSIGNMENT package body is a customization-layer PL/SQL unit in the Oracle E-Business Suite environment that provides a simplified wrapper around the standard Oracle Application Object Library (FND) responsibility-assignment APIs. Its principal business function is to grant (assign) and revoke Oracle EBS responsibilities for a given user account, an operation that in the base product is otherwise performed through the Users form or via the FND_USER_RESP_GROUPS_API. The package header carries the EBS source-control tag $Header: cctrsasb.pls 120.0 2005/06/02 09:30:56 appldev noship $, indicating it is a custom development artifact rather than a seeded Oracle module. The CCT_ prefix and noship designation confirm that it belongs to a customer extension rather than a standard product. In the ETRM classification it is recorded as an OTHER API, meaning it is not part of a formally published Oracle integration interface but exposes callable procedures that other custom components may invoke. In Oracle EBS 12.1.1 and 12.2.2 alike, the object resides in the APPS schema, is defined at the database tier, and is referenced by zero other packaged objects according to the metadata, so it functions as a leaf-level utility rather than a shared library dependency.

Key Procedures and Functions

The ETRM metadata records four documented program units and two distinct procedure names within the package body: ASSIGN_RESPONSIBILITY and REVOKE_RESPONSIBILITY. The four total entries reflect overloaded declarations of ASSIGN_RESPONSIBILITY.

• ASSIGN_RESPONSIBILITY (numeric overload) — Grants a responsibility to a user by delegating to Fnd_User_Resp_Groups_Api.UPLOAD_ASSIGNMENT. The caller supplies the user identifier together with the responsibility identifier and its owning application identifier. Internally the wrapper fixes the effective start date to the current system date, leaves the end date null (open-ended assignment), and passes a null description, producing a standard active responsibility assignment.
• ASSIGN_RESPONSIBILITY (key-based overload) — The convenience variant that accepts the responsibility key (the human-readable RESPONSIBILITY_KEY) instead of internal identifiers. It resolves the key by querying FND_RESPONSIBILITY_VL, extracts the corresponding responsibility and application identifiers, validates that a non-zero responsibility identifier was found, and then delegates to the numeric overload.
• REVOKE_RESPONSIBILITY — Terminates an existing user-to-responsibility assignment. It first calls Fnd_User_Resp_Groups_Api.Assignment_Exists to confirm the assignment is present; only when the check succeeds does it update FND_USER_RESP_GROUPS, setting END_DATE to the current system date for the matching user, responsibility, and application combination.

Tables Accessed

The package does not reference tables through its own APPS synonyms directly, but it operates on the following FND data structures through the underlying FND APIs or through embedded SQL:

• FND_USER_RESP_GROUPS — the central intersection table linking users to responsibilities. REVOKE_RESPONSIBILITY performs a direct UPDATE against END_DATE here, and the assignment path writes to the same table via UPLOAD_ASSIGNMENT.
• FND_RESPONSIBILITY_VL — the view over responsibility definitions used by the key-based overload to translate a RESPONSIBILITY_KEY into a RESPONSIBILITY_ID and APPLICATION_ID. It is read-only in this context.
• FND_RESPONSIBILITY / FND_APPLICATION — underlying base tables consulted by the FND API layer during assignment validation.

Usage Notes

This package is typically invoked from custom PL/SQL code, concurrent programs, or personalization handlers that must provision access without the interactive Users form. Because it wraps FND_USER_RESP_GROUPS_API, it inherits that API's validation and audit behavior; direct DML on FND_USER_RESP_GROUPS is confined to the revocation path. In both 12.1.1 and 12.2.2 the package behaves identically, though in a multi-tenant or Online Patching context the invoking session should run under a valid APPS initialization. Note that the numeric overload requires both the responsibility identifier and the owning application identifier, whereas the key overload resolves them automatically; callers should prefer the key overload when the responsibility key is known. Because the package is referenced by no other packaged object, changes to it are localized, but any dependent custom form or report should be regression-tested when the body is recompiled.