Search Results delete_task_assignment_post




Overview
Explore in AI Chat

Overview

APPS.JTF_TASK_ASSIGNMENTS_CUHK is a PL/SQL customization hook package belonging to the Oracle E-Business Suite CRM/Task Management (JTF) module. It is one of the standard "CUHK" (customization hook) packages that Oracle exposes so that implementers and partners can inject custom business logic into the lifecycle of the JTF Task Assignments entity without modifying Oracle's baseline application code. Task assignments represent the linkage between a task and the resource (person or group) responsible for executing it; they are created, updated, and deleted as part of the broader JTF Task Management flow driven by the Task Manager, Resource Manager, and related self-service or forms-based task screens.

The package declares no stateful business logic of its own in the shipped form — its procedures are effectively stubs that Oracle's framework invokes at defined points surrounding the base create, update, and delete operations. The package is compiled with AUTHID CURRENT_USER, and its header carries the source control identifier jtfctkas.pls 115.7 dated 2002/12/05, indicating that it has been part of the JTF task assignment stack since the 11i era and remains backward-compatible through 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes six documented procedures, organized as pre/post hook pairs around the three standard DML operations on task assignments:

  • create_task_assignment_pre — invoked immediately before a task assignment row is inserted. Custom validation logic can be placed here to reject or annotate the operation before the base insert executes.
  • create_task_assignment_post — invoked immediately after the base insert completes. This is the hook most commonly referenced when searching for create_task_assignment_post, and is the appropriate place to propagate the new assignment to downstream tables, send notifications, or call other integration APIs.
  • delete_task_assignment_pre — invoked before removal of an existing task assignment, allowing capture of the record's current state or enforcement of custom deletion rules.
  • delete_task_assignment_post — invoked after the assignment has been removed, typically used for cleanup or audit activity.
  • update_task_assignment_pre — invoked before an existing task assignment is modified, suitable for validating new values or capturing the pre-image.
  • update_task_assignment_post — invoked after an update has been applied, commonly used to synchronize dependent data.

All six procedures follow the same shape: they accept the standard task assignment record as input and return a status indicator, so that a failure raised inside a hook can be surfaced back to the calling framework.

Tables Accessed

The ETRM metadata for this package does not enumerate any direct table references via APPS synonyms, which is consistent with its role as a thin customization hook: the package's contract is the record structure it accepts, not the underlying DML. The record type it consumes is defined in the sibling package JTF_TASK_ASSIGNMENTS_PUB, and the base tables that the public API maintains — principally the JTF_TASK_ASSIGNMENTS table and its associated object-version and assignment-history tables — are manipulated by that public API rather than by this hook package itself. Implementers writing custom logic into the pre/post procedures would normally join to JTF_TASK_ASSIGNMENTS, JTF_TASKS_B, and resource-related views, but such access is a customization concern rather than a documented behavior of the shipped package.

Usage Notes

JTF_TASK_ASSIGNMENTS_CUHK is not intended to be called directly by end-user code as a primary API. Instead, it is invoked internally by Oracle's task assignment framework (typically through JTF_TASK_ASSIGNMENTS_PUB) at the pre and post points of each create, update, and delete. The standard customization pattern is to edit the package body — leaving the specification intact — and place site-specific PL/SQL inside the relevant procedure. Because the framework catches and processes the returned status code, custom code should handle exceptions deliberately and set the return status rather than allowing unhandled errors to propagate. The package is referenced by zero other packages in the ETRM registry, confirming it is a leaf-level hook rather than a shared utility. Modifications should be treated as patches: Oracle does not upgrade hook bodies, so any customization must be re-applied after applying a patch that replaces the package. Given the AUTHID CURRENT_USER directive, all unqualified object references resolve to the schema of the invoking session, so custom code should fully qualify or rely on APPS synonyms.