Bookings and Booking Requests

The booking area turns a member's wish to use a boat into a confirmed trip. It also gives the team one place to see what every boat is doing now and what it is expected to do next.

Why there are three booking tools

The three tools answer different questions:

A booking is a confirmed use of a specific boat. A booking request is only a request for time, place, and usually a boat type. Treating them as the same thing would make an unconfirmed request block the fleet as if it were already final.

Two ways a trip starts

Direct booking

Use a direct booking when the operator already knows the member, boat, place, and dates. Before saving, the system checks the information needed to price the trip and checks whether the boat is available.

Booking request

Use a request when the member has expressed a preference but the final boat is not yet agreed. A request records:

• the requested start and end time;
• the location;
• either a boat type or a specific boat;
• the member;
• an optional comment.

This lets the team keep the demand visible without pretending that a boat has already been assigned.

What the calendar is for

The calendar is the daily planning view. Its colors distinguish confirmed bookings, checked-in and checked-out trips, cancellations, expired items, requests, reserved requests, blocked periods, service visits, and charter use. It can also warn that a member is using a boat outside the home region.

The color is only a visual aid. Always open the item before making an important decision: the saved status and dates are the real record.

Common uses are:

• checking that two members are not promised the same boat;
• finding a replacement boat when one needs service;
• seeing which trips should already have started or ended;
• separating member trips from service work and blocked time.

Turning a request into a booking

The admin action is called Solve. In business terms, it means “we found a workable boat and converted this request into a real booking.”

flowchart LR
    A[Member request] --> B[Check dates, place and boat type]
    B --> C{Suitable boat available?}
    C -- No --> D[Keep request open and contact member]
    C -- Yes --> E[Calculate trip price and club days]
    E --> F[Create confirmed booking]
    F --> G[Mark request as solved]

If the request names only a boat type, the system looks for boats of that type that are available for the requested time. If none are available, the request stays open so the operator can offer another time, place, or boat type.

The created booking contains the member, selected boat, dates, place, calculated price and currency, planned club-day use, comment, and the fact that an admin created it. Extra services are not added automatically in this path.

Important partial-failure rule

The system first creates the booking and only then marks the request as solved. If the second step fails, the request may still look open even though a booking already exists.

Before pressing Solve again:

1. search the booking list for the member and dates;
2. open any matching booking and verify its boat;
3. only retry the missing status change when it is safe.

A blind retry can create a duplicate booking.

Reopening a solved request

The Unsolve action changes the request back to an unsolved state. It does not cancel or remove the booking that was created from it. This is intentional: reopening a request and cancelling a member's trip are different business decisions.

Before unsolving, decide what should happen to the related booking. Cancel or change it separately if required by the operating policy.

Rules an operator should understand

• Availability depends on the boat, dates, location, active state, and other bookings or blocks in the same period.
• Price depends on the member, boat or boat type, location, dates, currency, and the pricing records in force.
• An administrator can confirm an overlapping booking only through the explicit override path. It should be a conscious exception, not the normal process.
• A request status does not by itself prove that every related side effect, such as a message, was delivered.

When something looks wrong

Technical reference

For developers tracing this feature, the main entry points are admin/templates/bookings/calendar.hbs, admin/js/renderers/calendar-widget.js, admin/js/actions/bookings.js, and apps/admin/src/Controller/BookingRequestController.php. The request status operation is PATCH /api/v1/booking-requests/{id}/set-status.