rsvp_reservation_eca: standalone recipe for reservation workflow automation

Context

The rsvp_reservation_workflow recipe provides the structural layer — content type, fields, views, routes, and the ReservationConflict entity validation constraint (confirmed built + kernel-tested). ECA automation is a separate concern and ships in its own recipe so the structural recipe stays stable while ECA models can evolve independently.

ECA 3.0.11 is installed. Currently enabled: eca, eca_content, eca_ui. The BPMN modeller (eca_modeller_bpmn) and eca_workflow, eca_base, eca_user are all disabled — the recipe will enable what's needed.

Phase 1: Research before building

• Review ECA 3.x changelog and sub-module capabilities — especially eca_modeller_bpmn vs eca_ui for model authoring
• Determine which sub-modules are needed: eca_workflow (status transitions?), eca_base, eca_user, eca_content (already enabled)
• Confirm whether reservation status (field_reservation_status, a list_string) is handled by eca_content actions or needs eca_workflow
• Check if any new condition/action plugins in 3.x simplify the overlap query or field comparison patterns

Phase 2: Custom PHP — ResourceAvailabilityCondition plugin

File: rsvp-system-module/src/Plugin/ECA/Condition/ResourceAvailabilityCondition.php

An ECA Condition Plugin that wraps the same overlap query used by ReservationConflict (the entity validation constraint). Returns TRUE (available) or FALSE (conflict). Used by ECA models that need to check availability before auto-creating tentative reservations.

No ECA plugin directory exists in the module yet — this creates it.

Phase 3: ECA models to build

Build in the BPMN modeller UI, then export as config entities into the recipe.

Model A: Reservation status transition side effects

Trigger on field_reservation_status change. Per transition:

• Created → Tentative: notify resource manager
• Tentative → Confirmed: notify requestor
• Any → Cancelled: notify requestor; release slot signal
• Any → Rejected: notify requestor with reason
• Any → Conflict: notify manager (flag needs review)

Model B: EventSeries recurrence-edit warning + pre-cancel

On EventSeries pre-save when recurrence pattern changes: query linked EventInstances for confirmed reservations. If found, surface a blocking warning to the editor. Cancel those reservation records before recurring_events destroys the instances — prevents orphaned reservations.

Model C: Auto-tentative on EventInstance create

On EventInstance create: if parent EventSeries has field_preferred_resource set and field_series_booking_mode = auto-tentative, run ResourceAvailabilityCondition. If available, auto-create a Tentative reservation and link it. If conflict, set status to conflict and notify manager.

Phase 4: Recipe

New recipe: rsvp-recipes/recipes/rsvp_reservation_eca/

• Depends on rsvp_reservation_workflow
• Enables required ECA sub-modules (determined in Phase 1)
• Imports ECA model config entities (exported from BPMN modeller)
• Documents that rsvp_system_module must be at a version including ResourceAvailabilityCondition

Definition of Done

• ResourceAvailabilityCondition ECA plugin exists and is discoverable in the ECA UI
• Model A: changing reservation status triggers correct notification action
• Model B: editing a series recurrence pattern with confirmed reservations surfaces warning and cancels reservations cleanly
• Model C: EventInstance create with preferred resource auto-creates tentative reservation or flags conflict
• All three models exported to recipe config and recipe applies cleanly on fresh install
• ADR-0017 Implementation Status table updated

Related

• ADR-0017 — Resource reservation architecture, conflict detection, series problem
• ADR-0028 — Event date change → reservation sync (already implemented in PHP hooks, not ECA)
• ReservationConflict constraint — confirmed built; ResourceAvailabilityCondition is its ECA companion