Booking App 1.4¶

Context Summary¶

To be used for final testing

RCAS Booking App v1.4 — Context Summary
End of development session — 11 August 2026

Current milestone¶

The central v1.4 workflow is now functioning end-to-end. The guiding development principle remains:

Move responsibility. Test. Then change behaviour.

Tonight was the point where the architecture stopped merely observing bookings and began making and executing booking decisions.

Current architecture¶

Code Base 1. `Index.html` — Receptionist¶

Responsible for the tutor-facing experience:

booking form;
browser-side validation;
Review Booking screen;
Back to Edit;
Confirm Booking;
sending currentBooking through google.script.run;
displaying the result returned by the server.

No booking decisions are made here.

One small UI improvement remains outstanding: the green success message currently persists after the form resets. We intend to clear it automatically after approximately five seconds.

Code Base 2. `BookingLogic.gs` — Booking Manager¶

This is now the centre of booking business logic.

Important working functions:

evaluateBooking_(formData)
findRoomConflict_(calendar, room, startDateTime, endDateTime)
createCalendarEvent_(calendar, booking)
buildConflictNote_(conflict, room)

evaluateBooking_() now does more than report facts.

It:

gets the target calendar;
normalises the requested room;
constructs startDateTime and endDateTime;
calls findRoomConflict_();
determines whether the request should be Approved or Pending;
constructs the tutor-facing message;
constructs the administrative processingNote;
logs the evaluation;
returns the result to submitBooking().

Its decision is essentially:

Conflict?
   │
   ├── Yes → Pending
   │
   └── No  → Approved

For a free room, the Processing Note initially returned by evaluation is:

Automatically approved for Gallery.

or Studio.

For a conflict, buildConflictNote_() identifies the conflicting calendar event, producing a useful note such as:

Conflict detected: Gallery is already booked by
"Testing Warmer Chemises (Gallery)".

The actual implementation should be treated as authoritative tomorrow; this summary records the intended behaviour.

Code Base 3. `Code.gs`¶

web-app entry point / transaction coordinator

submitBooking(formData) still receives the booking from the browser and performs the established server-side validation and tutor lookup.

The important architectural change tonight was moving:

evaluateBooking_(formData)

inside the ScriptLock.

Previously the lock essentially meant:

Wait your turn to write.

It now means:

Wait your turn to decide and reserve.

The protected transaction is becoming:

Acquire ScriptLock
        ↓
Evaluate booking
        ↓
Decide Approved / Pending
        ↓
Write worksheet row
        ↓
Write Processing Note
        ↓
If Approved:
    create calendar event
        ↓
    retrieve Event ID
        ↓
    store Event ID
        ↓
    update Processing Note
        ↓
Release ScriptLock

This is essential concurrency protection.

Two simultaneous submissions cannot both check the calendar before either has reserved the room. The second request must wait until the first transaction has created its calendar event and released the lock.

Automatic Approved pathway — now working¶

For a booking with no calendar conflict:

Tutor confirms
      ↓
Lock acquired
      ↓
evaluateBooking_()
      ↓
No conflict
      ↓
Approved
      ↓
worksheet row written
      ↓
calendar event created
      ↓
Calendar Event ID retrieved
      ↓
Event ID stored in worksheet
      ↓
Processing Note updated
      ↓
lock released

The event uses the existing reusable:

createCalendarEvent_(calendar, booking)

The booking object contains:

{
  fullName,
  email,
  courseName,
  room,
  startDateTime,
  endDateTime
}

The Calendar title is now Course Name first, as requested by TPTB, so the month view shows the course rather than the tutor.

Automatic Pending pathway — now working¶

If findRoomConflict_() discovers an existing event in the requested room:

Tutor confirms
      ↓
Lock acquired
      ↓
evaluateBooking_()
      ↓
Conflict
      ↓
Pending
      ↓
worksheet row written
      ↓
Processing Note explains conflict
      ↓
NO calendar event
      ↓
NO Calendar Event ID
      ↓
review-required message returned
      ↓
lock released

The tutor sees:

Your booking has been recorded for review because the room may already be booked.

This is the heart of the v1.4 requirement:

Ordinary bookings are handled automatically. Only exceptions require volunteer attention.

Testing completed tonight¶

Several increasingly complete tests succeeded.

Automatic approval¶

A free booking was submitted through the web form.

The system correctly:

returned Approved;
wrote Approved to the worksheet;
created the corresponding test-calendar event;
used Course Name as the calendar title;
stored the room as Calendar Location;
included tutor/course information in the description.

Calendar Event ID¶

A subsequent free booking confirmed that an automatically created event's ID is retrieved with:

const eventId = event.getId();

and written into the corresponding worksheet row.

Thus the worksheet record and its calendar reservation are now linked.

Real automatic conflict¶

This was the most important test.

Ellen Montville booked:

Testing Warmer Petticoats
Gallery
17 August
11:00–16:00

The system automatically Approved it, created the calendar event and stored its Event ID.

Harriet then requested the same Gallery:

17 August
14:00–18:00

The requests partially overlapped.

The system correctly:

detected Ellen's automatically created calendar event;
marked Harriet's booking Pending;
created no second calendar event;
left Harriet's Event ID blank;
returned the review-required browser message.

This proves that an automatically processed booking can prevent a subsequent overlapping automatic booking from being approved.

Processing Notes¶

Another pair of bookings confirmed that Processing Notes are being written.

The Approved row received an automatic-approval note.

The Pending row identified the actual conflicting Calendar event by title.

Final edit made tonight¶

needs first test tomorrow

For an Approved booking, evaluateBooking_() initially supplies:

processingNote: conflict
  ? buildConflictNote_(conflict, room)
  : `Automatically approved for ${room}.`

After the calendar event has actually been created and its Event ID successfully stored, Code.gs now updates the Processing Note to:

sheet.getRange(row, procNoteCol).setValue(
  `Automatically approved. Calendar event created in ${evaluation.room}.`
);

This was deliberately placed after:

sheet.getRange(row, eventIdCol).setValue(eventId);

so the worksheet does not claim successful calendar creation before the event has actually been created and linked.

This final refinement has been saved but has not yet been tested.

That should be tomorrow's first test.

Tomorrow — Arty-Farty¶

regression-testing day ☕🎨

No major development should be undertaken before regression testing.

While everyone is painting and Robyn is performing the inevitable barista duties, test the current system systematically.

Suggested checks:

Ordinary free booking
Approved;
event created;
Event ID stored;
final Processing Note says calendar event created.
Overlapping same-room booking
Pending;
no event;
blank Event ID;
conflict Processing Note;
correct tutor-facing message.
Same time, different room
both bookings should be Approved.
Adjacent bookings
e.g. 10:00–12:00 followed by 12:00–14:00;
both should be Approved.
Manual exception pathway
take a Pending booking;
resolve whatever caused the conflict;
change Status manually to Approved;
confirm the existing onEdit/manual approval machinery creates exactly one event and stores its Event ID.
Duplicate protection
ensure an Approved row already containing an Event ID cannot accidentally generate another calendar event.
Cancellation/status-change behaviour
worth confirming the existing v1.3 mechanisms still correctly remove linked live events.

Small UI cleanup¶

Still outstanding in Index.html.

After:

showMessage(response.message, 'success');

we intend to add:

setTimeout(function () {
  clearMessage();
}, 5000);

This allows the green confirmation message to remain visible for five seconds after successful submission and then disappear automatically.

This is cosmetic and should not interfere with tomorrow's functional testing.

Demo for Those Interested¶

The afternoon demonstration can be very simple.

Demonstration 1 — ordinary booking¶

Enter a booking for a free room/time.

Show:

Submit
  ↓
Approved
  ↓
Calendar event appears

No volunteer intervention.

Demonstration 2 — exception¶

Submit another request overlapping that event in the same room.

Show:

Submit
  ↓
Pending
  ↓
No duplicate calendar reservation
  ↓
Processing Note explains why

The essential message for RCAS is:

You no longer need to approve every booking. The system handles ordinary bookings and asks you to deal only with the exceptions.

Exact stopping point¶

The central v1.4 automatic workflow is now operational.

Do not begin tomorrow by adding more features.

Begin with one ordinary free booking to verify tonight's final Processing Note change.

Then regression-test the existing behaviour.

If those tests pass, the next development question is the manual Pending → Approved exception pathway, followed by cleanup and consolidation.

Tonight's milestone is:

The Booking Manager can now decide whether a booking should be Approved or Pending, reserve an available room, link that reservation to the worksheet, and stop conflicting requests for human review—all within one protected transaction.

That's an excellent place to close the workshop for the night. 🔑🌿

And tomorrow, naturally, the Booking Manager will have to wait until the barista has supplied the painters with coffee. Some hierarchies cannot safely be automated. ☕😄