{{--
Edit Document — CR-15 §3.3, decisions D1/D14/D15.
**There is no wireframe page for this screen.** The v12 pack draws
upload-document.html and add-upload-document.html and nothing else for this
module, so decision D14 fixes the design by reference instead: follow
add-upload-document.html's form language. That is what this file does, block
for block —
* a Reference section with the same `.form-section-title` icon
(`fa-link`), showing the booking, the person and the Booking Type chip as
READ-ONLY context;
* ONE Document Details block with the same `fa-file-upload` heading, the
Document Type select on the left and the file control on the right in the
wireframe's `.form-row.form-row-2`;
* the Remark Notes section, unchanged;
* the `.card-footer` with Cancel then the primary action, in v12's order.
## What this screen is NOT
* **It is not the create screen's twin.** They are not a create/edit pair
in recipe §9's sense: the upload screen is a repeater that writes N rows
against a person the user chooses, and this one edits ONE existing row
whose person and booking are fixed. TwinViewParityTest is deliberately
not extended to pair them (CR-15 §4.4) — asserting that a repeater and a
single-document form render the same field names would assert something
false.
* **It has no Add More**, for the same reason.
* **It cannot move the document to another person or another booking**
(decision D1). A document belongs to who it was uploaded for; the wrong
person means delete and re-upload. The two facts are drawn as text, not
as controls, and neither is in UpdateCustomerDocumentRequest's rule set —
so a hand-rolled post carrying either cannot reach validated().
## The file control has two states, and replacing is OPTIONAL (D15)
The current file is drawn in the wireframe's own "Row 2" selected-file panel
(add-upload-document.html:190-197) with a drop zone beneath it. Choosing a
new file swaps the panel for the chosen one; choosing nothing leaves the
bytes exactly as they are and only the type and the remark change.
A browser will not let a server refill a file input, so on a rejected submit
the error renders and the picker comes back empty — the stored file is still
there and still shown, which is the honest rendering of "nothing was
replaced".
## No lang file (CR-15 §0.3)
Every string on this screen is written here, on the client's instruction.
--}}
@extends('layouts.app')
@section('title', 'Edit Document')
@section('breadcrumbs')
@endsection
@section('content')
@php
/** @var \App\Models\CustomerDoc $document */
/** @var \App\Models\Booking $booking */
$person = $document->customer;
/*
* Everything the client module can put on screen, in one attribute. This
* screen needs only the two the file panel writes; the module holds no
* wording of its own.
*/
$strings = [
'file_uploaded' => 'Selected',
'row_title' => 'Document',
];
@endphp
{{-- Display controls, not inputs: neither value is editable and
neither posts anything. `.customer-display` is the same
class the booking tab's fixed Customer control uses, so the
two screens' read-only fields have one set of metrics. --}}
{{-- The list is the mapped, active types MINUS the ones this
person already holds — with THIS row ignored, so the
current type is always in it and the screen can be
re-saved unchanged. CustomerDocumentController::
availableDocTypes() and UpdateCustomerDocumentRequest
derive that from the same two helpers.
`required` is re-armed client-side from the
data-validate-* attributes: the field's `exists` rule
keeps it off the generated rule set entirely (see
clientRuleExclusions()). --}}
{{-- The CURRENT file, in the wireframe's own selected-
file panel. Always visible: it describes what is
stored, and a replacement does not change that until
the form is saved. --}}
{{ $document->original_name }}
Current file
@can('customer_documents.view')
@endcan
{{-- The REPLACEMENT, once one is picked. Hidden until
then; the module fills the two spans with
textContent — the filename is the one untrusted
string on this screen. --}}