POST /tms/transloads/break-queue¶
What it does¶
/tms/transloads/break-queue accepts POST and is declared in app/systems/TMS/transload/api_routes.php:445 as a path.
The route handler delegates to tmsTransloadApiBreakQueueCreate(). That function is the owner of
this behaviour; the route entry is only dispatch.
Call chain:
- →
tmsTransloadApiBreakQueueCreate()—app/systems/TMS/transload/work_queue_api_helper.php:96 - ↳
tmsTransloadApiBreakQueueAssertCanManage()—app/systems/TMS/transload/work_queue_api_helper.php:89 - ↳
tmsTransloadApiBreakQueueCanManage()—app/systems/TMS/transload/work_queue_api_helper.php:84
Who calls it¶
Called from:
frontend/pages/system/TMS/transload/inbound-planning.php
A caller is the strongest available evidence of the intended use.
Input¶
| Where | Key |
|---|---|
body |
LOADER_ID |
body |
LOADER_NAME |
Request bodies must not use TYPE, ACTION or USERNAME as contract fields.
Output¶
| Key |
|---|
ID |
Success is { "data": …, "requestId": "…" }.
Failure is { "error": { "code", "message" }, "requestId": "…" }.
SQL executed¶
INSERT INTO T_LOADING_PLANNER
Data¶
Tables reached from the owner function:
T_LOADING_PLANNER
Access¶
- module-gated on
tms.transload, so tenant module access applies
Validation and failure messages¶
- Loader is required.
- Manager permission is required.
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.