Update a claim
Requires claims:view permission. Users without claims:manage permission can only update their own claims.
Approval orchestration: When status is changed to approved (from any other status) and no remadePane exists yet, the system automatically:
- Creates a new remake pane with the same specs as the original (dimensions, rawGlass, jobType, glassType, processes, edgeTasks, routing) cloned from the original pane.
- If
remakeStation(Station ObjectId) is provided, the remake pane is placed at that station (currentStation: <remakeStation>,currentStatus: pending). If omitted,currentStationisnull(queued). The pane is created withorder: null. - The remake pane belongs to the same request as the original order (
requestis copied). - The remake pane’s
remakeOffield points to the original defective pane. - The claim’s
remadePanefield is set to the new pane’s ID. - A
MaterialLogentry withactionType: remakeis created. - Real-time events are emitted:
pane:updated,station:pane_arrived(to the target station room ifremakeStationwas provided), and anotificationto the original order’sassignedToworker.
The frontend should send remakeStation with the ObjectId of the order release station (identified by its OrderReleasePanel UI block).
This fires regardless of the decision field (both keep and destroy). Setting status to rejected does not create a remake pane. Re-approving an already-approved claim (or one that already has a remadePane) does not create a duplicate.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Resource ID
Body
customer, worker 111broken, chipped, dimension_wrong, scratch, stain, other Station ObjectId where defect was found
pending, approved, rejected destroy, keep 111Station ObjectId where the remake pane should land (e.g. order release station). Frontend sends this when approving a claim.
1