{{--
    The Booking Action cell of the Inquiries DataTable —
    docs/wireframes-v12/inquiry.html (~line 136): a per-row `<select>` whose
    options either navigate or open one of the three modals below the table.

    The wireframe draws FIVE of them and so does this partial — for a user who
    holds `bookings.create`. A user without it gets FOUR: "Booking" is not
    rendered at all since CR-14 §4.4, which the section on that option below
    explains in full.

    **And a booking-confirmed inquiry gets NO select at all** (CR-6.2 item K4):
    the cell is the em-dash, for every viewer including a Super Admin. See "The
    lock" below.

    Rendered by InquiriesDataTable through rawColumns(['booking_action']), so
    **this output is injected into the page unescaped** and the same rule as
    projects/partials/actions.blade.php applies: nothing user-controlled may
    reach it except through an escaped attribute. Everything dynamic here is in
    ONE `data-inquiry` JSON attribute, written with `{{ }}` — which escapes the
    JSON for an HTML attribute — and read by nrems-inquiry-actions.js with
    JSON.parse. The option labels are lang strings and the values are a closed
    list of five constants, of which four or five are rendered depending on the
    viewer's `bookings.create` — a permission answer, not user data.

    What the payload holds, and why each key is in it:

        id, project_id      the tentative modal's unit options are fetched from
                            the cascade endpoint scoped to this row's project,
                            with this row's own hold ignored;
        tentative_unit_id,  the modal opens prefilled with the hold this
        hold_until          inquiry already has, so "extend by a week" is one
                            field, not two;
        urls                where each of the three forms should post, and where
                            "Add Follow up journey" and "Booking" navigate.
                            Generated server-side from the model key, so the
                            client never builds a url out of an id.

    Note there is no customer name, no phone and no code in the payload: the
    modals do not show them, so the one genuinely attacker-supplied field on the
    row never reaches a script at all.

    ## The "Booking" option (CR-6 §1, wired by CR-6.1, withheld by CR-14 §4.4)

    CR-6 §1 left "Booking" rendering exactly as designed and doing nothing,
    because the Booking module did not exist. It does now, so the option
    navigates to the New Booking screen prefilled from this inquiry — the same
    `bookings.create?inquiry={id}` destination the "Proceed to Booking" button
    of inquiries/partials/proceed-to-booking.blade.php uses.

    **A user without `bookings.create` no longer sees the option at all.** CR-6.1
    left it rendered-but-inert for them: the payload arrived without a `booking`
    url and the JS fell through to the reset, on the reasoning that the client's
    screen shows five options and an inert one is friendlier than a 403. The
    client has since asked for removal (CR-14 §4.4), and on reflection that is
    the better shape anyway — an option that silently does nothing when picked is
    indistinguishable from a broken page, where an option that is not there says
    what it means. The paragraphs that used to argue the other way are gone
    rather than left standing beside the code that contradicts them.

    The option and the url are governed by ONE `can('bookings.create')` check, so
    they can never disagree: the PHP block below withholds the url and the gate
    around the `<option>` withholds the control. The JS needs no change — it
    looks up `urls[value]` for whatever was selected, and neither half exists.

    ## The lock (CR-6.2 items K1/K4) — and the open question it CLOSES

    CR-6.1 left one product question standing: the Booking option was still
    offered on an inquiry that had already been booked, on the reasoning that
    the booking form would refuse the second one anyway. **The client has now
    answered it**, verbatim: *"Once Booking Confirm for any inquiry then no one
    can edit, delete that inquiry and also Booking action can do it once inquiry
    booking confirm."* So the question is closed, and not only for the Booking
    option — the whole select goes.

    A `booking_confirm` inquiry renders the em-dash instead of the control, its
    `$urls` is empty and no `data-inquiry` attribute is written at all. "No one"
    includes a Super Admin, which is why the predicate is a STATE comparison
    (Inquiry::isLockedByBooking()) and not a permission: `Gate::before` hands a
    Super Admin every ability, so a policy arm would have locked everybody
    except the account the client's sentence most needs to cover.

    It is not one-way. BookingService reverts the inquiry's status when the
    booking is CANCELLED (CR-9), so the select comes back by itself — which is
    correct, and is stated here because a reader who only saw the locking half
    would reasonably assume otherwise.

    (A note this file earned the hard way, and which an earlier version of it
    got half wrong. The hazard is **the raw-block delimiters only** — the two
    tokens that open and close a PHP block — as literal text anywhere they are
    not meant as delimiters. BladeCompiler::compileString() calls
    storeUncompiledBlocks() FIRST, whose `/(?<!@)@php(.*?)@endphp/s` is lazy, so
    naming the opening one inside a comment starts a block early and swallows
    this comment's own terminator, and naming the closing one inside a real
    block ends it early and spills the code after it into the template as HTML.
    Both were shipped here in one afternoon and both broke every draw of this
    listing.

    Ordinary directive names — `@can` and friends — are safe BOTH here and
    inside a PHP block, and the earlier claim that they were unsafe in the
    latter was simply false. Measured: a `@can` written in a comment inside a
    PHP block produces compiled output containing neither `Gate` nor `if (`,
    because the block was hoisted out before the directive pass ever ran. So
    this comment may name them, and does.)

    ## Gating

    Every one of the five destinations is a write or a write form, so the whole
    control is behind `update`. A view-only user gets the wireframe's em-dash
    rather than a dropdown that 403s on selection.

    "Booking" carries a SECOND gate because it is the one destination outside
    this module: creating a booking is `bookings.create`, which InquiryPolicy
    knows nothing about, and the two permissions are held independently. That
    second gate is now what decides whether the option is DRAWN, not merely
    whether it works.

    yajra hands the row's model in as $model.
--}}
@php
    /** @var \App\Models\Inquiry $model */

    // CR-6.2 item K4. A booking-confirmed inquiry has no action left to record,
    // so it gets no control and no payload — not a control with an empty one.
    // The predicate is a status comparison on a model this row is already
    // holding, so it costs nothing per row (Inquiry::isLockedByBooking()).
    $locked = $model->isLockedByBooking();

    $urls = $locked ? [] : [
        'follow_up' => route('inquiries.follow_up', $model),
        'hold' => route('inquiries.hold', $model),
        'meeting' => route('inquiries.meeting', $model),
        'not_interested' => route('inquiries.not_interested', $model),
    ];

    // Only for a viewer who may actually create a booking (CR-6.1 C1). Since
    // CR-14 §4.4 the same answer also decides whether the <option> is rendered
    // at all — see the gate around it below — so a user without the permission
    // gets neither the control nor a url it could have pointed at.
    //
    // (Ordinary Blade directive names are SAFE in this block — it is hoisted
    // out of the template before the directive pass runs — so the only token
    // that must not appear here is the one that CLOSES a raw block, which would
    // end this one early and spill the lines below into the page as HTML. See
    // the docblock above for the matching hazard on the other side.)
    $canBook = ! $locked && auth()->user()?->can('bookings.create') === true;

    if ($canBook) {
        $urls['booking'] = route('bookings.create', ['inquiry' => $model->getKey()]);
    }

    $payload = [
        'id' => $model->getKey(),
        'project_id' => $model->project_id,
        'tentative_unit_id' => $model->tentative_unit_id,
        'hold_until' => $model->hold_until?->format('Y-m-d'),
        'urls' => $urls,
    ];
@endphp
@if (! $locked)
@can('update', $model)
    <div class="booking-action-wrapper">
        <label class="visually-hidden" for="booking_action_{{ $model->getKey() }}">{{ __('inquiries.booking_action.label') }}</label>
        <select class="form-control booking-action-select"
                id="booking_action_{{ $model->getKey() }}"
                data-inquiry="{{ json_encode($payload, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) }}">
            <option value="">{{ __('inquiries.booking_action.placeholder') }}</option>
            <option value="followup">{{ __('inquiries.booking_action.follow_up') }}</option>
            <option value="tentative">{{ __('inquiries.booking_action.tentative') }}</option>
            <option value="meeting">{{ __('inquiries.booking_action.meeting') }}</option>
            @if ($canBook)
                <option value="booking">{{ __('inquiries.booking_action.booking') }}</option>
            @endif
            <option value="notinterested">{{ __('inquiries.booking_action.not_interested') }}</option>
        </select>
    </div>
@else
    <span class="text-muted" aria-hidden="true">&mdash;</span>
@endcan
@else
    {{-- CR-6.2 item K4: booking-confirmed, so there is no action left to record
         and the cell is the app's blank. Nothing is disabled and nothing inert
         is left behind to explain — and because the whole control is withheld,
         so is the `data-inquiry` payload, which is what item K4 means by "what
         you may not do has no address". --}}
    <span class="text-muted" aria-hidden="true">&mdash;</span>
@endif