Mobile NDT Request – Feature Guide

Overview

The NDT Request screen in the mobile app lets users enter or update NDT request information (request dates, NDT company) for weld log joints. Data is saved via the Dynamic Resource API to the weld_logs table.

Where to Find It

Mobile app: Sidebar → NDT Request (under NDT / ndt-entry module).
The screen lists weld logs; you can filter by Line, ISO, Spool, Joint, etc., then open a row to edit NDT fields.

What You Can Do

Set request date per NDT type: VT, RT, UT, PT, MT, PMI, PWHT, HT, Ferrite.
Select NDT Company (subcontractors with job_description = NDT).
Save changes; the app sends only the modified fields to the backend.

API Used

All read and save operations use the Dynamic Resource API:

Action	Endpoint	Description
List weld logs	`POST /api/weld_logs/read`	Filter, sort, paginate; columns requested by the app.
Save (update)	`POST /api/weld_logs/update`	Body: `id`, `values` (key-value pairs for changed fields).

So for save we use /api/weld_logs/update, not a separate “save” endpoint. The backend handler is DynamicResourceController::handle with table = weld_logs, action = update.

Backend Validation Rule

When saving from the mobile app (or any client using the API), the backend applies this rule for weld_logs:

New request not allowed if:
- The joint has welding_date set, or
- The joint has any *_request_no already set (e.g. VT, RT, UT, PT, MT, PMI, PWHT, HT, Ferrite).
Allowed: Updating an existing request (e.g. changing request date when that NDT type already has a request_no), or adding a first request when the joint has no welding_date and no request numbers.

If the rule is violated, the API returns 422 with a message like:
"New request entry is not allowed for this joint (welding date exists or request already exists). Only changes to existing requests are allowed."

Request Number (request_no)

request_no (e.g. pt_request_no, vt_request_no) is generated by the SaveTrigger system (e.g. RequestDateOperationsTrigger).
On the web (Admin panel), it is triggered after save via ExecuteSaveTriggerJob from AdminController::saveJson.
On the API path (/api/weld_logs/update), the SaveTrigger is not run in the current implementation, so request_no may not be auto-filled when saving from the mobile app. If request numbers are required for API updates, the backend may need to run the same trigger logic (or an equivalent) after API update.

Testing

Use weld log rows that have no welding_date and no *_request_no to test “first request” (e.g. PT Request Date). See ndt-request-pt-test-data.md for eligible test IDs and steps.
For rows with existing request numbers, you can test updating request dates or NDT company; the validation allows updates to existing requests.

ndt-request-pt-test-data.md – Test data and steps for PT request date.
dynamic-api-and-scribe-guide.md – Dynamic API overview.
save-trigger-system-guide.md – SaveTrigger and request_no generation.

3.2 KiB Raw Blame History Unescape Escape