# 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.

## Related Docs

- **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.