{{--
Booking Details — docs/wireframes-v12/view-booking.html, rebuilt on the
wireframe's own markup.
v12's layout, top to bottom:
1. a status row: the enlarged status pill on the left, Print / Edit /
Cancel Booking on the right;
2. a card carrying the three-tab strip and the panels under it;
3. the Basic tab: a `.grid-2` of the Customer Details and Unit Details
cards, then the Contact Person card.
The tabs are v12's three links, upgraded in place by nrems-tabs.js — the
wireframe points them at three separate pages (view-booking.html,
document-list.html, booking-history.html) and CR-8 §3.6 asks for same-page
panels, which is also what the edit screen does. Consistent, and one request
instead of three.
## Deliberate differences from the wireframe
* **The Payment Summary card is not rendered** (client: "financial not
required", CR-8 §1). Nothing on this screen mentions money.
* **PAN and Aadhaar rows are dropped** (decision D12). The wireframe draws
both in Customer Details and no screen in this module captures either —
a detail row cannot show data that was never collected, and inventing
the columns to fill them would be inventing a requirement.
* **Tower / Block, Floor, Unit Type and Built-up Area and Facing are
dropped from Unit Details** for the same reason: CR-5 §15.1 reduced
`units` to a number, an area and a status, so Project / Unit No. /
Carpet Area is the whole of what exists.
* **The Co-Owner row becomes one row per co-owner.** The wireframe writes
a single "Sonal Patel (Spouse)"; there is no relationship field in this
module and there can be more than one co-owner, so each gets a row and
the parenthesis goes.
* **Nothing is ADDED to either card.** Every difference above is a
removal, which is what decision D12 authorises; §4 fixes the row lists
and this screen renders exactly them. Occupation, Address, Booking Date,
Booking Entity Type, Inquiry and Assigned Sales Person are all
maintained on the edit form and none of them is drawn here.
* **Dates are `d M Y`**, the format the rest of this module writes
(`config('nrems.date_format')` is `d-m-Y` and is what the *inquiries*
detail screen uses — mixing the two inside one module would be the
drift, so nothing on this screen reads it).
* **Print is `window.print()`** — the wireframe's button has no behaviour
at all. It is the one inline handler on this page and it carries no
data; a print stylesheet is future work.
## No lang file (CR-8 §0.1)
Every string on this screen is written here, on the client's instruction.
## Escaping
Every value on this page is user-supplied text and every one goes out
through `{{ }}`. The only `{!! !!}` is none: this file has no raw output at
all.
--}}
@extends('layouts.app')
@section('title', 'Booking Details - '.$booking->code)
@section('breadcrumbs')
@endsection
@section('content')
@php
// Rendered as a dash rather than an empty cell, so an unanswered row
// still reads as a row — the projects and inquiries detail screens'
// own idiom.
$blank = '—';
$main = $booking->mainCustomer;
$coOwners = $booking->customers->where('is_co_owner', 1);
$cancelled = $booking->isCancelled();
// The "Through its" row's label is the booking type's own title from
// Booking::THROUGH_MAP — the same constant the form's block is titled
// from and the same one the required-when rule reads, so the three can
// never name different people. Null for a type with no block, and the
// row is then not drawn at all.
$throughTitle = $booking->throughTitle();
@endphp
{{-- The wireframe's Print button, given the only behaviour it can
honestly have. Inline, and deliberately: it carries no data, it
is one call, and a module file for it would be a file that
exists to avoid one attribute. --}}
@can('bookings.edit')
@unless ($cancelled)
Edit
@endunless
@endcan
@can('cancellations.create')
@unless ($cancelled)
{{-- A LINK now, not a POST form (CR-9 §3.4). It used to post
to `bookings.cancel` behind a confirm() dialog, because
a GET that changes data would be fired by any crawler or
prefetch — and that reasoning has not changed. What
changed is that this button no longer changes anything:
a cancellation records a reason, a date, who asked, a
stage and a document checklist, and a dialog cannot
collect any of it. The Initiate Cancellation screen it
opens, with this booking preselected, IS the
confirmation step now.
The gate moved with it — `cancellations.create` rather
than `bookings.delete`, which gated deleting a customer
document until CR-15 decision D3 moved that onto
`customer_documents.delete` and now gates nothing.
The look is unchanged: `btn btn-danger btn-sm` and
`fa-ban`, exactly as view-booking.html draws it. --}}
Cancel Booking
@endunless
@endcan
{{-- v12 nests this tab's cards INSIDE the tabs card's own `.card-body`
(view-booking.html:87-94: one `.card`, the `.tabs` strip, then
`.card-body` holding the grid) — so the panel below is that card-body
and not a sibling of the card. The edit screen deliberately does NOT do
this: edit-booking.html:89-98 draws its strip in a card of its own with
the panels beneath it, and the two wireframes differ. --}}
{{-- Customer Details: the wireframe's six rows minus PAN and
Aadhaar (decision D12 — no columns exist for either). Nothing
is ADDED to the list: an Occupation and an Address row were
here briefly and are gone, because §4 fixes what this card
shows and D12 authorises removals only. Both values are on the
edit form, which is where they are maintained. --}}
Booking Details{{ $main?->name ?? $blank }}
Phone{{ $main?->mobile_number ?? $blank }}
Email{{ $main?->email ?: $blank }}
{{-- One row per co-owner, in the order the party is stored.
The wireframe's single row with a relationship in
brackets has no data behind it — see the header. --}}
@forelse ($coOwners as $coOwner)
Co-Owner{{ $coOwner->name }}
@empty
Co-Owner{{ $blank }}
@endforelse
{{-- Unit Details: Project / Unit No. / Carpet Area and nothing
else. The wireframe's other five rows (Tower / Block, Floor,
Unit Type, Built-up Area, Facing) are dropped because CR-5
§15.1 reduced `units` to a number, an area and a status — and
nothing is added in their place for the reason the Customer
card records. --}}
Project{{ $booking->project?->name ?? $blank }}
Unit No.{{ $booking->unit?->unit_number ?? $blank }}
Mobile Number{{ $booking->contact_mobile ?: $blank }}
Email{{ $booking->contact_email ?: $blank }}
Address{{ $booking->contact_address ?: $blank }}
{{-- Only drawn when the booking type has a block and a name was
given — "Karta — Mahesh Patel", the wireframe's own shape. --}}
@if ($throughTitle !== null && filled($booking->through_name))
Through its{{ str_replace('Through its ', '', $throughTitle) }} — {{ $booking->through_name }}
@endif
{{-- The other two panels stay OUTSIDE the tabs card. v12 gives each of them
a page of its own (document-list.html, booking-history.html) and each
of those pages draws its content as a card; CR-8 §3.6 asks for
same-page panels instead, so the card each page had is the card each
panel gets. Nesting them in the strip's card-body as well would have
put a card inside a card-body inside a card. --}}
{{-- No "Back to Bookings" button. view-inquiry.html draws one and
view-booking.html does not, and §4's list of what this screen carries
does not include it — the breadcrumb and the sidebar are both a click
away. Added here in the first pass and removed: a control the client's
design does not have is a change to the design. --}}
{{-- The Documents tab's delete confirmation (CR-15.3 item H2). At the END of
the content section and outside every `.card`, for the clipping reason
the partial's own header records. It also pushes the toaster and the
delete client, which is why the tab's buttons need nothing of their
own. --}}
@include('customer-documents.partials.delete-modal')
@endsection
@push('scripts')
{{-- Progressive enhancement: every panel is rendered visible and this
module hides the inactive ones on load, so with no Javascript the whole
booking — details, documents and history — is still on the page. It
does nothing at all on a page without [data-nrems-tabs]. --}}
@endpush