instruction-rules¶

TMS > tms.transload

What it does¶

/tms/transloads/instruction-rules accepts PATCH and is declared in app/systems/TMS/transload/api_routes.php:581 as a path.

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

Call chain:

→ tmsTransloadApiInstructionRulesUpdate() — app/systems/TMS/transload/request_api_helper.php:224
↳ tmsTransloadInstructionEnabled() — app/systems/TMS/transload/request_api_helper.php:71
↳ tenant_config_get_bool() — app/platform/tenant/config_helper.php:730

Who calls it¶

Called from:

frontend/pages/platform/admin-console/instruction-rules.php
public/assets/js/modules/tms/transload-instruction-rules.js

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

Input¶

Where	Key
`body`	`RULES`
`body`	`rules`

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

Output¶

The response is produced by a shared helper, so the key set is not visible at the route. Read the owner function to confirm the shape before writing a client.

Data¶

No table reference is visible in the owner function body.

Access¶

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

Validation and failure messages¶

Transload instructions are disabled for this tenant.
At least one valid instruction rule 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.

PATCH /tms/transloads/instruction-rules¶