{{-- Add New Inquiry — docs/wireframes-v12/add-inquiry.html (the card at ~lines 84-458: six form sections and the footer). ## Shape ONE `.card`. Inside it, a `.form-section` per heading — each with its `.form-section-title` and the wireframe's own icon — and a `.card-footer` at the bottom. Fields are laid out by v12's `.form-row.form-row-2/-3` grids, not by Bootstrap columns, which is why no field carries a `group-class`: the row owns the columns and `.form-group` owns its own margin. The page title is v12's own header wording, "Add New Inquiry", which is longer than the breadcrumb crumb ("Add Inquiry") on the same wireframe page. ## The twin rule (recipe §9) This file and inquiries/edit.blade.php are twins. Every field is written out in both, and neither includes a shared form partial. **A field added, removed or renamed here must be mirrored in edit.blade.php in the same commit.** TwinViewParityTest renders both screens and fails when their `name` sets or their required-attribute sets differ. It does not compare labels, order or validation rules, so those are on whoever edits the pair. ### What this screen has that its twin does not * it posts to `inquiries.store` as a POST, where the twin PUTs to `inquiries.update` and therefore carries a `_method` field; * its rule source is StoreInquiryRequest; the twin's is UpdateInquiryRequest (which differs only in `authorize()` and in letting `hold_until` be in the past — see that class); * its breadcrumb trail ends "Add Inquiry"; the twin's ends with the inquiry's code; * every control renders empty. The twin prefills all of them from the inquiry, including the two conditional source blocks and the tentative section, and loads the project's units into both unit selects with the inquiry's own hold ignored; * the twin renders no Inquiry Conclusion prefill either, and that is NOT a difference in field set — see the note on the section below. ## Deliberate differences from the wireframe * **Inquiry Source offers WALK-IN.** add-inquiry.html's mock select stops at WEBSITE, but inquiry.html's filter and view-inquiry.html's Source row both have Walk-in, so an inquiry can be one and this form has to be able to say so (CR-6 §2.2, §9 assumption 5). The select iterates the enum rather than repeating the mock's five options. * **Site Visit and Follow Up Call star every field of their sub-panel.** add-inquiry.html stars only Site Visit's Assigned To and none of Follow Up Call's, but follow-up.html stars all of them and CR-6 §2.3 makes them required. The data rule wins over one screen's asterisks (recipe §0: where HTML and spec disagree on *data*, the spec governs), and the other wireframe agrees with the spec. * **The Not Interested panel is real, not a preview.** add-inquiry.html draws it as a red-dashed explanatory block below the Interested tab ("Not Interested tab content (shown when...)"). CR-6 §5.2 asks for it to be built as the tab's actual content, so the tab pair switches between the nine options and this panel, and the wireframe's own tints are what the panel is painted with. * **"Proceed to Booking" stays inert on THIS screen, and only this one.** CR-8 §3.5 wired the button on the three inquiry screens that have an inquiry to book; this one does not — the inquiry is being typed and has no id yet, so there is nothing to pass to the booking form. It is therefore still a disabled {{-- Which tab was active is a posted value, because the server reads a different half of the payload for each (see FollowUpRecorder::entriesFromInquiryForm()). --}} {{-- The Not Interested tab's real content. See "Deliberate differences" above on why this is a panel and not the wireframe's explanatory preview. --}} {{-- v12's card footer: Cancel as the outline button, the inert Proceed to Booking in the wireframe's success fill, then the primary action, all right-aligned inside the card's bottom rule. `.card-footer` is already the flex row, so no wrapper of its own. --}} {{-- The conditional, unit-cascade and conclusion rules are excluded from the client rule set: every one of them is conditional on another control's value, and proengsoft has no vocabulary for that — it would mark an untouched Broker select invalid on a walk-in inquiry rather than render nothing. The server validates all of them. See StoreInquiryRequest::clientRuleExclusions(). --}} @endsection @push('styles') @include('inquiries.partials.styles') @endpush @push('scripts') {{-- The inquiry form client (CR-6 §5.2). ES5, no build step, no dependency, and it does nothing at all on a page without #nrems_inquiry_form_module. Every string it can put on screen comes in from Blade through one JSON data-attribute, and every option it builds lands through createElement/textContent — never innerHTML. --}} @endpush