The v1.3 line tightens up the parts of the plugin that were “fine for one resource per page, not so fine for ten.” Per-service approval workflows route bookings to the right maintainer when a single page hosts a mix of resources with different owners. The public booking flow grew real inline validation that catches errors as you type instead of waiting for submission. And under the hood, the database tables got a safer prefix and an atomic migration to match.

v1.3 spans v1.3.0 through v1.3.7. Backward-compatible end to end; the per-service feature defaults off, and the table rename is idempotent.

What’s new in v1.3

Per-service approval workflows

Until now, approval rules in booknslot were page-level: one set of maintainers for every resource on the page. Workable when all the resources have the same owner — a fleet of identical vehicles, say. Awkward when they don’t:

Vehicle 1 is owned by the Engineering motor pool; Vehicle 2 by Facilities.
Conference Room A needs approval from the room manager; the Phone Booth auto-approves.
Lab equipment routes to the lab manager; the shared printer doesn’t need approval at all.

A new “Per-service approval” toggle in Builder Step 4 turns on per-resource configuration:

Each resource gets its own requiresApproval flag (overrides the page default).
Each resource gets its own list of assigned maintainers.
Each resource gets its own approverCount (how many maintainers need to approve before the booking confirms — useful for high-stakes resources requiring two signatures).

Stored in JSON inside the existing schema, so no migration is needed — the toggle is purely additive. Default is off; existing pages keep their page-level rules until you flip it.

Per-resource visibility scoping

A subtle but important security fix that ships alongside per-service approval: the /bookings API and the approval queue now scope the maintainer’s visibility to only the resources they’re assigned to. A maintainer for Vehicle 1 cannot see Vehicle 2’s bookings, approve them, or see them in their .ics deliveries.

Previously, anyone with booknslot_approve capability could see every pending booking on every page they were assigned to a maintainer for. Fine for small teams; problematic the moment a single page hosts multiple resources with separate maintainers. v1.3.1 fixes this so per-resource scoping is enforced end to end — list view, approve endpoint, ICS attachment recipients.

Full client-side validation in the public booking flow

The public booking widget previously deferred most validation to the server: you’d fill the form, click Continue, get bounced back with an error if something was wrong. v1.3.7 ships inline validation across every step:

Full name and email required, with email-shaped regex check.
Each custom form field validates per its type: text/textarea required if marked required, select must match a real option, checkbox must be ticked if required, email-type fields must look like emails.
The Continue button stays disabled until every required field passes.
Step 1 also checks that the chosen slot still exists (race-condition catch — slot got booked while you were filling the form).
Step 2 OTP input has numeric input mode, pattern="[0-9]{6}", maxLength=6, and inline 1–5 digit error message.

Internally this is built on a small shared component infrastructure (Inp, SelectField, TextAreaField with error, onBlur, and inputMode props) — the same primitives will let us add new field types cleanly in future releases.

What got better

Table prefix renamed to `wp_booknslot_`

The plugin’s tables previously used the short prefix wp_bm_. Short prefixes occasionally collide with other plugins that also default to two-letter abbreviations. v1.3.2 ships an atomic multi-table RENAME on first admin load post-upgrade that renames every wp_bm_* table to wp_booknslot_* in a single transaction.

Idempotent: re-running on a fresh install (or a site that’s already been migrated) is a no-op.
Atomic: either every table renames or none do — no possibility of a half-migrated state.
Backward-compatible: existing data carries over byte-for-byte; only the table name changes.

After the migration, the prefix is unambiguous and won’t collide with another plugin’s bm_* tables. The decision-record reasoning is in the project docs; the user-visible answer is “your bookings are still there; everything’s just named more clearly now.”

Calendar auto-picks the first bookable day

When you open a booking page, the calendar previously defaulted to today’s date — which was confusing on pages with a lead-time requirement (e.g., “must be booked at least 24 hours in advance”). The booker would land on today, see no slots, and assume the page was broken.

As of v1.3.3, the calendar auto-picks the first day on which slots are actually bookable when it loads. Past days and lead-time-only days now display a status=unavailable indicator instead of being clickable but empty — you can tell at a glance which days are “not bookable” vs “no slots configured.”

`.ics` emails to the approving maintainer

Booking-confirmation emails always included an .ics attachment for the booker. v1.3.6 extends that to the maintainer who approved the booking — they get the same calendar entry in their own inbox so the approval shows up on their calendar without manual re-entry.

Useful for facility managers who want all the bookings they’ve approved on their own calendar without configuring a separate iCal subscription.

Auto-approved bookings no longer crash

A pair of bugs in v1.3.4 and v1.3.5 affected pages with auto-approve enabled and .ics attachment configured:

v1.3.4: wp_mail() was crashing on auto-approved bookings because the .ics temp-file path relied on wp_tempnam() returning a value that some hosts don’t provide. Fixed by falling back to PHP’s native tempnam() + get_temp_dir(). Internal fix; user-visible as “the confirmation screen and email now both appear cleanly.”
v1.3.5: A second crash on the confirmation-screen render when no approval was required (the front-end was checking for an approval object that doesn’t exist in the auto-approve path). Fixed; auto-approve bookings now reach the “Booking confirmed” screen reliably.

Both of these only affected the auto-approve flow; manual-approval bookings were unaffected. If you were on v1.3.0–v1.3.3 with auto-approve on, v1.3.5+ is the fix.

What’s coming next

The v1.4 line is already in active development:

Bookings calendar view — week and month grids with booking chips, replacing the long list as the default Bookings tab view. Includes a filter bar (status pills, page/resource dropdowns) and a side drawer that opens on click with the full booking record + approve/reject actions in one place.
Per-service form fields — fields that show only for specific resources. Vehicle 1’s form asks for a license plate; the conference room’s doesn’t. New resource_label column on the form-fields table with an automatic migration.
Email delivery simplification — dropping the Resend HTTP-API dependency in favor of WordPress’s native wp_mail(). Configure SMTP via any of the existing WP plugins you already trust; no API keys to manage in the booknslot settings.
Multi-slot booking — bookers select a contiguous range of slots in one transaction (up to a configurable per-page maximum), so a 3-hour vehicle reservation isn’t three separate bookings.
ITS-readiness hardening — explicit GDPR/FERPA export and erase hooks (so the WordPress privacy tools page can scrub booker data on request), OTP rate-limiting, and a honeypot field against bot bookings.

Where to go from here

Update from Plugins → Installed Plugins → Update. The table-rename migration runs automatically on first admin load. Existing bookings, maintainers, pages, and settings carry over with no manual intervention. The per-service approval toggle defaults to off; flip it per page when you want the finer-grained routing.

If you’re evaluating, the live demo walks through a single booking end-to-end on mock data — about 90 seconds, OTP code 123456 for the verification step.

For the full feature breakdown, see What makes booknslot different.