Skip to content

POST /tms/transloads/reopen-for-retransload/dip-recovery

TMS > tms.transload

What it does

/tms/transloads/reopen-for-retransload/dip-recovery accepts POST and is declared in app/systems/TMS/transload/api_routes.php:139 as a path.

The route handler delegates to tmsTransloadReopenDipRecoveryConfirm(). That function is the owner of this behaviour; the route entry is only dispatch.

Call chain:

  1. → tmsTransloadReopenDipRecoveryConfirm() — app/systems/TMS/transload/reopen_retransload_helper.php:333
  2. ↳ tmsTransloadReopenAssertOffice() — app/systems/TMS/transload/reopen_retransload_helper.php:6
  3. ↳ getEffectiveRoleIds() — config/config.php:1066

Who calls it

Called from:

  • app/systems/TMS/transload/reopen_retransload_helper.php

A caller is the strongest available evidence of the intended use.

Input

Where Key
body TRANSLOAD_ID

Request bodies must not use TYPE, ACTION or USERNAME as contract fields.

Output

Key
AUDIT_ID
OPERATION_EVENT_ID
STATUS
TRANSLOAD_ID

Success is { "data": …, "requestId": "…" }. Failure is { "error": { "code", "message" }, "requestId": "…" }.

SQL executed

SELECT ROLE_ID FROM T_USER WHERE ID = ? AND CLIENT_ID = ? AND DELETED_AT IS NULL LIMIT 1

Data

Tables reached from the owner function:

  • T_TRANSLOAD

Access

  • module-gated on tms.transload, so tenant module access applies

Validation and failure messages

  • Transload is required.
  • Operation event storage is unavailable.
  • Reopen for Re-transload is restricted to office users.

These strings come from the owner function and are the messages a client can receive. They are also the cheapest way to tell a rejected request from a broken one.