Decommission Easy!Appointments + n8n booking-sync #25

New Issue

2026-07-23T14:07:59+02:00

mivanchenko commented

2026-07-23 14:07:59 +02:00

Parent

What to build

Full cutover: retire Easy!Appointments and its sync bridge now that the in-house booking module
covers everything it did.

Repoint every client's landing-page iframe (starting with happynails) from the EA embed to the
new /book/<slug> page.
Tear down deploy/booking/ (the easyappointments + ea-db containers and their compose
stack).
Delete n8n/booking-sync.json (fully superseded by ticket 9's internal webhook).
No data migration — existing EA bookings are placeholder data and are discarded.
Verify and close #1 (EA reschedule PK-conflict bug) as a side effect: the failure mode cannot
occur once bookings are written directly via ticket 1/2's EXCLUDE-constraint-backed path
instead of synced in from EA.

Acceptance criteria

All live clients' landing pages embed the new /book/<slug> page instead of the EA iframe.
The easyappointments and ea-db containers are stopped and removed; deploy/booking/ is
either deleted or clearly marked decommissioned.
n8n/booking-sync.json is removed from the live n8n instance and from the repo.
A new booking made through the new public page appears correctly in the owner's calendar
view, confirmation email, and Telegram notification — full path verified end to end on a
live (or staging) client.
#1 is closed with a comment explaining why it's moot post-cutover.

Blocked by

#17 (Public booking page + iframe embed)
#18 (Booking confirmation email + customer self-service cancel/reschedule)
#20 (Owner calendar view + manual booking + owner cancel/reschedule)
#21 (Owner settings: services, hours/buffer, auto-confirm, notify channel)
#22 (Per-client ICS calendar feed)
#23 (Owner notification webhook)
#24 (New-client onboarding automation update)

## Parent #14 ## What to build Full cutover: retire Easy!Appointments and its sync bridge now that the in-house booking module covers everything it did. - Repoint every client's landing-page iframe (starting with happynails) from the EA embed to the new `/book/<slug>` page. - Tear down `deploy/booking/` (the `easyappointments` + `ea-db` containers and their compose stack). - Delete `n8n/booking-sync.json` (fully superseded by ticket 9's internal webhook). - No data migration — existing EA bookings are placeholder data and are discarded. - Verify and close #1 (EA reschedule PK-conflict bug) as a side effect: the failure mode cannot occur once bookings are written directly via ticket 1/2's `EXCLUDE`-constraint-backed path instead of synced in from EA. ## Acceptance criteria - [ ] All live clients' landing pages embed the new `/book/<slug>` page instead of the EA iframe. - [ ] The `easyappointments` and `ea-db` containers are stopped and removed; `deploy/booking/` is either deleted or clearly marked decommissioned. - [ ] `n8n/booking-sync.json` is removed from the live n8n instance and from the repo. - [ ] A new booking made through the new public page appears correctly in the owner's calendar view, confirmation email, and Telegram notification — full path verified end to end on a live (or staging) client. - [ ] #1 is closed with a comment explaining why it's moot post-cutover. ## Blocked by - #17 (Public booking page + iframe embed) - #18 (Booking confirmation email + customer self-service cancel/reschedule) - #20 (Owner calendar view + manual booking + owner cancel/reschedule) - #21 (Owner settings: services, hours/buffer, auto-confirm, notify channel) - #22 (Per-client ICS calendar feed) - #23 (Owner notification webhook) - #24 (New-client onboarding automation update)

mivanchenko added the ready-for-agent enhancement booking labels 2026-07-23 14:08:00 +02:00

mivanchenko added a new dependency 2026-07-23 14:09:18 +02:00

#17 Public booking page + iframe embed

mivanchenko added a new dependency 2026-07-23 14:09:18 +02:00

#18 Booking confirmation email + customer self-service cancel/reschedule

mivanchenko added a new dependency 2026-07-23 14:09:18 +02:00

#20 Owner calendar view + manual booking + owner cancel/reschedule

mivanchenko added a new dependency 2026-07-23 14:09:18 +02:00

#21 Owner settings: services, hours/buffer, auto-confirm, notify channel

mivanchenko added a new dependency 2026-07-23 14:09:19 +02:00

#22 Per-client ICS calendar feed

mivanchenko added a new dependency 2026-07-23 14:09:19 +02:00

#23 Owner notification webhook (Telegram re-point)

mivanchenko added a new dependency 2026-07-23 14:09:19 +02:00

#24 New-client onboarding automation update

mivanchenko referenced this issue

2026-07-23 14:09:55 +02:00

Booking POST is a plain INSERT — reschedule re-fires EA-<id> and 500s on PK conflict #1

mivanchenko commented

2026-07-23 14:43:41 +02:00

Deploy-pipeline grill (paused, resume once the new booking app/blueprints exist):

deploy-booking.yml will be a new, separate Gitea Actions workflow — not merged into deploy-backoffice.yml.
It is not a "deploy the new app" pipeline: the booking module (booking_db.py etc.) lives inside the same Flask app/container that deploy-backoffice.yml already deploys (confirmed via the #15 commit — rsync of backoffice/app/ and the idempotent init.sql apply already cover it, no changes needed there).
So deploy-booking.yml is really this ticket's cutover pipeline: EA + n8n booking-sync decommission, once the new module fully replaces it.
Cutover is naturally two phases:
1. Per-client iframe repoint (edit each deploy/clients/<slug>/site/index.html iframe src, redeploy that client) — doesn't need a dedicated pipeline, it's just a normal client-content deploy.
2. Final teardown (stop easyappointments/ea-db, remove deploy/booking/, delete n8n/booking-sync.json) — the open candidate for what deploy-booking.yml should actually automate.
Open question for when we resume: should the teardown step be a guarded one-shot workflow_dispatch (e.g. a confirmation-string input, since it's destructive with no rollback — though per this ticket's body, EA data is placeholder and discarded anyway), and does it need to do anything beyond the teardown steps already listed in this ticket's acceptance criteria?

Deploy-pipeline grill (paused, resume once the new booking app/blueprints exist): - `deploy-booking.yml` will be a new, separate Gitea Actions workflow — not merged into `deploy-backoffice.yml`. - It is **not** a "deploy the new app" pipeline: the booking module (`booking_db.py` etc.) lives inside the same Flask app/container that `deploy-backoffice.yml` already deploys (confirmed via the #15 commit — rsync of `backoffice/app/` and the idempotent `init.sql` apply already cover it, no changes needed there). - So `deploy-booking.yml` is really **this ticket's cutover pipeline**: EA + n8n booking-sync decommission, once the new module fully replaces it. - Cutover is naturally two phases: 1. **Per-client iframe repoint** (edit each `deploy/clients/<slug>/site/index.html` iframe `src`, redeploy that client) — doesn't need a dedicated pipeline, it's just a normal client-content deploy. 2. **Final teardown** (stop `easyappointments`/`ea-db`, remove `deploy/booking/`, delete `n8n/booking-sync.json`) — the open candidate for what `deploy-booking.yml` should actually automate. - Open question for when we resume: should the teardown step be a guarded one-shot `workflow_dispatch` (e.g. a confirmation-string input, since it's destructive with no rollback — though per this ticket's body, EA data is placeholder and discarded anyway), and does it need to do anything beyond the teardown steps already listed in this ticket's acceptance criteria?

Sign in to join this conversation.