dependancies and docs
This commit is contained in:
Vendored
+3
-1
@@ -1 +1,3 @@
|
||||
{}
|
||||
{
|
||||
"readableLineLength": true
|
||||
}
|
||||
Vendored
+5
-1
@@ -171,8 +171,12 @@
|
||||
},
|
||||
"active": "0e456d61bc5b6ded",
|
||||
"lastOpenFiles": [
|
||||
"Crussell/Test Implementation Plan.md",
|
||||
"Crussell/Technical Manual.md",
|
||||
"Crussell/User Manual.md",
|
||||
"Crussell/Admin Manual.md",
|
||||
"Crussell/Overview.md",
|
||||
"Crussell/Future Work - Gap Backlog.md",
|
||||
"Crussell/Test Implementation Plan.md",
|
||||
"Crussell/Crussell Nails.md",
|
||||
"Crussell/Backend/bookings.md",
|
||||
"Untitled.base",
|
||||
|
||||
@@ -18,18 +18,18 @@ No external dependencies. No paid services. No API keys needed.
|
||||
|
||||
## P1 — High
|
||||
|
||||
| # | Gap | Effort | Area | Notes |
|
||||
|---|-----|--------|------|-------|
|
||||
| 5 | **Admin notification panel** | M (1-2d) | Frontend | Backend fully wired (GET/acknowledge). No frontend UI to display notifications. Admin has no visibility into pending bookings, cancellations, no-shows. |
|
||||
| 6 | **Reservation/anonymization cron** | S (2-3h) | Backend | `CleanupOldReservations()` and `AnonymizeStaleGuestAccounts()` only fire on availability fetch. If no one fetches availability, expired reservations persist and stale guests aren't anonymized. Should be a background ticker in `main.go`. |
|
||||
| 7 | **GDPR data export endpoint** | M (1d) | Backend | `export_all_user_data()` SQL function exists (JSON export). No Go handler wired. Required for GDPR Article 15 SAR requests. |
|
||||
| 8 | **VAT/Tax export endpoints** | M (1-2d) | Backend | `get_vat_return_data()`, `export_sales_transactions()` SQL functions exist. No admin API to trigger them. Needed for HMRC compliance. |
|
||||
| ~~9~~ | ~~**Walk-in guest reservation → booking transition**~~ ✅ | S (1h) | Frontend | Done — guest accounts created at submit time, reservation system uses explicit reservation_type field, both walk-in and call-in use 15min TTL. |
|
||||
| 10 | **Password reset flow not wired to frontend** | S (2-3h) | Frontend | Backend has `/api/verify/generate` and `/api/verify/check` endpoints. Login page has no "forgot password" link or form. |
|
||||
| 11 | **Email verification flow not wired to frontend** | S (2-3h) | Frontend | Users register with `unverified_email` role. No UI to enter verification code or resend code. `+layout.svelte` has alert-based prototype. |
|
||||
| 12 | **Booking cancellation from user account** | S (2-3h) | Frontend | UserBookingModal shows booking details but no cancel button. Users must call/email to cancel. Backend endpoint exists (`DELETE /api/bookings/{id}`). |
|
||||
| 13 | ~~**Booking rescheduling for users**~~ ⚠️ | M (1-2d) | Full-stack | Backend fully wired (request/approve/deny + time_blocker reservation). Frontend re-validation on submit implemented. **Remaining:** Admin UI to view/approve/deny edit requests — consider extending existing Pending Approvals panel. User notification on approve/deny tracked as TODO (blocked on E5). |
|
||||
| 50 | **Admin UI for edit request approval/denial** | M (1-2d) | Frontend | Backend endpoints exist: `GET /api/admin/bookings/{id}/edit-requests`, `POST .../approve`, `POST .../deny`. Needs UI to display pending requests with proposed vs original time, approve/deny buttons. **Consider:** Extend existing Pending Approvals panel on Today page rather than building separate page. |
|
||||
| # | Gap | Effort | Area | Notes |
|
||||
| ----- | -------------------------------------------------------- | -------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 5 | **Admin notification panel** | M (1-2d) | Frontend | Backend fully wired (GET/acknowledge). No frontend UI to display notifications. Admin has no visibility into pending bookings, cancellations, no-shows. |
|
||||
| 6 | **Reservation/anonymization cron** | S (2-3h) | Backend | `CleanupOldReservations()` and `AnonymizeStaleGuestAccounts()` only fire on availability fetch. If no one fetches availability, expired reservations persist and stale guests aren't anonymized. Should be a background ticker in `main.go`. |
|
||||
| 7 | **GDPR data export endpoint** | M (1d) | Backend | `export_all_user_data()` SQL function exists (JSON export). No Go handler wired. Required for GDPR Article 15 SAR requests. |
|
||||
| 8 | **VAT/Tax export endpoints** | M (1-2d) | Backend | `get_vat_return_data()`, `export_sales_transactions()` SQL functions exist. No admin API to trigger them. Needed for HMRC compliance. |
|
||||
| ~~9~~ | ~~**Walk-in guest reservation → booking transition**~~ ✅ | S (1h) | Frontend | Done — guest accounts created at submit time, reservation system uses explicit reservation_type field, both walk-in and call-in use 15min TTL. |
|
||||
| 10 | **Password reset flow not wired to frontend** | S (2-3h) | Frontend | Backend has `/api/verify/generate` and `/api/verify/check` endpoints. Login page has no "forgot password" link or form. |
|
||||
| 11 | **Email verification flow not wired to frontend** | S (2-3h) | Frontend | Users register with `unverified_email` role. No UI to enter verification code or resend code. `+layout.svelte` has alert-based prototype. |
|
||||
| 12 | **Booking cancellation from user account** | S (2-3h) | Frontend | UserBookingModal shows booking details but no cancel button. Users must call/email to cancel. Backend endpoint exists (`DELETE /api/bookings/{id}`). |
|
||||
| 13 | ~~**Booking rescheduling for users**~~ ⚠️ | M (1-2d) | Full-stack | Backend fully wired (request/approve/deny + time_blocker reservation). Frontend re-validation on submit implemented. **Remaining:** Admin UI to view/approve/deny edit requests — consider extending existing Pending Approvals panel. User notification on approve/deny tracked as TODO (blocked on E5). |
|
||||
| 50 | **Admin UI for edit request approval/denial** | M (1-2d) | Frontend | Backend endpoints exist: `GET /api/admin/bookings/{id}/edit-requests`, `POST .../approve`, `POST .../deny`. Needs UI to display pending requests with proposed vs original time, approve/deny buttons. **Consider:** Extend existing Pending Approvals panel on Today page rather than building separate page. |
|
||||
|
||||
## P2 — Medium
|
||||
|
||||
|
||||
Reference in New Issue
Block a user