feat: Enhance reservation functionality
This commit is contained in:
73
docs/planning/user-stories.md
Normal file
73
docs/planning/user-stories.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# User Stories
|
||||
|
||||
## Open Reservations (Crew Sign-up)
|
||||
|
||||
A reservation can be marked **open**, meaning other members can sign up as crew. Skippers control whether joining is open (anyone can join) or requires approval.
|
||||
|
||||
| ID | Persona | Story |
|
||||
|----|---------|-------|
|
||||
| US-01 | Member | As a Member, I want to be able to make Open Reservations, so that other members can sign up to be crew. |
|
||||
| US-02 | Member | As a Member, I want to be able to join an open reservation as crew, so I can sail with a skilled skipper. |
|
||||
| US-03 | Member | As a Member, I want to be able to manage my registration to join a reservation, so I can free up the spot if I can't make it. |
|
||||
| US-04 | Skipper | As a skipper, I want to note details about the sailing reservation, to help others decide if they want to join. |
|
||||
| US-05 | Skipper | As a skipper, I want to be able to set an open reservation as "anyone can join" or "approval required." |
|
||||
| US-06 | Skipper | As a skipper, I want to be able to approve crew members, so that I can ensure I have the right mix of people/skills. |
|
||||
| US-07 | Skipper | As a skipper, I want to be able to add members, and non-members to my reservation, regardless of whether it is open or not. |
|
||||
|
||||
## Notifications
|
||||
|
||||
| ID | Persona | Story | Phase |
|
||||
|----|---------|-------|-------|
|
||||
| US-08 | Member | As a member, I want to be notified in a dedicated Discord channel whenever a new open reservation is created, so that I can join these sailings. | Near-term |
|
||||
| US-09 | Member | As a member, I want to receive SMS or in-app notifications for events like: upcoming reservation reminders, crew-joined notifications, etc. | Longer-term |
|
||||
|
||||
**Notes:**
|
||||
- US-08 (Discord): POST to a Discord webhook when an open reservation is created. Likely an Edge Function triggered on insert. The channel and webhook URL are configuration values.
|
||||
- US-09 (SMS/in-app): Requires a notification service (e.g. Twilio for SMS, or Supabase Realtime + push for in-app). Defer until after launch.
|
||||
|
||||
## Check-out / Check-in Forms
|
||||
|
||||
Required pre-sail and post-sail paperwork. Both skipper and crew may submit.
|
||||
|
||||
| ID | Persona | Story |
|
||||
|----|---------|-------|
|
||||
| US-10 | Skipper / Crew | As a skipper or crew member, I want to submit the check-out and check-in forms, which are required. |
|
||||
| US-11 | Skipper | As a skipper, I would like reminders to fill out the check-out/in forms at the beginning and end of my reservation. |
|
||||
|
||||
**Notes:**
|
||||
- US-10: Form fields TBD — likely: condition notes, crew list, fuel level, departure/return times.
|
||||
- US-11: Reminder timing — check-out reminder at reservation start time; check-in reminder at reservation end time. Notification channel TBD (Discord, SMS, or in-app per US-08/09).
|
||||
- Both stories depend on the check-out/in form schema being defined with the Program Administrator.
|
||||
|
||||
## Member Profiles
|
||||
|
||||
Members can view each other's profiles. Some fields are always public; others are selectable public/private by the member.
|
||||
|
||||
| ID | Persona | Story |
|
||||
|----|---------|-------|
|
||||
| US-12 | Member | As a member, I want to be able to see profile information of other members, like a social network site. |
|
||||
| US-13 | Member | As a member, I want to control which parts of my profile are public or private. |
|
||||
|
||||
**Known visibility rules:**
|
||||
|
||||
| Field | Visibility |
|
||||
|-------|------------|
|
||||
| First name, Last name | Always public |
|
||||
| Certifications | Always public (relevant to crew sign-up) |
|
||||
| Email | Member-controlled (public / private) |
|
||||
| Phone | Member-controlled (public / private) |
|
||||
|
||||
**Notes:**
|
||||
- US-12: Profile view should be accessible by clicking a member's name anywhere it appears in the app (e.g. schedule, crew list).
|
||||
- US-13: Privacy settings stored per-field on the `members` row (e.g. `email_public: boolean`, `phone_public: boolean`). Enforced via RLS or a view that filters hidden fields for non-owners.
|
||||
- Admin can always see all fields regardless of member's privacy setting.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- [ ] US-07: What constitutes a "non-member"? Does a non-member need an account, or just a name on the reservation?
|
||||
- [ ] US-05: Is approval per-crew-member (skipper approves each request) or a toggle that gates all join requests?
|
||||
- [ ] US-10: What fields are on the check-out/in forms? Are these the same forms as the current paper process?
|
||||
- [ ] US-11: Which notification channel is available for form reminders before US-09 is implemented?
|
||||
- [ ] US-08: Discord webhook URL and channel name — stored in Vault at `kv/oys/`?
|
||||
- [ ] US-13: Full list of member-controlled fields — is phone already in the schema? Any other fields (e.g. Slack ID, bio)?
|
||||
- [ ] US-13: Should privacy enforcement be RLS on the `members` table, or a separate `member_profiles` view that masks hidden fields?
|
||||
@@ -82,9 +82,25 @@
|
||||
|
||||
---
|
||||
|
||||
## Planned Features (not yet built)
|
||||
|
||||
See `docs/planning/user-stories.md` for full stories and open questions.
|
||||
|
||||
| Feature | Stories | Phase |
|
||||
|---------|---------|-------|
|
||||
| Open Reservations + crew sign-up | US-01 – US-07 | Near-term |
|
||||
| Discord notifications (open reservations) | US-08 | Near-term |
|
||||
| Check-out / Check-in forms | US-10, US-11 | Near-term |
|
||||
| SMS / in-app notifications | US-09 | Longer-term |
|
||||
|
||||
---
|
||||
|
||||
## Open Items
|
||||
|
||||
- [ ] Are cancel-reservation and admin Edge Functions planned?
|
||||
- [ ] What is the full set of admin pages needed?
|
||||
- [ ] What is the club name for display in the app?
|
||||
- [X] What is the season start date / go-live target?
|
||||
- [ ] US-07: What constitutes a "non-member" on a reservation?
|
||||
- [ ] US-10: What fields are on the check-out/in forms?
|
||||
- [ ] US-08: Discord webhook URL / channel — confirm stored in Vault at kv/oys/
|
||||
|
||||
@@ -0,0 +1,124 @@
|
||||
# Session Handoff: Schedule Interactivity, Admin Features, Routing Fix
|
||||
**Date:** 2026-04-22
|
||||
**Session Duration:** ~3 hours
|
||||
**Session Focus:** Fixed IonRouterOutlet route params bug; made schedule page fully interactive on desktop; added admin create/edit capabilities; added member names to schedule; documented Ionic+Nuxt watch-outs and new user stories.
|
||||
**Context Usage at Handoff:** ~85%
|
||||
|
||||
---
|
||||
|
||||
## What Was Accomplished
|
||||
|
||||
1. **Diagnosed and fixed `params: {}` bug on edit page** → root cause: Nuxt's auto-imported `useRoute()` always returns empty params inside IonRouterOutlet. Fix: `import { useRoute, useRouter } from 'vue-router'` directly. Documented in CLAUDE.md under "Ionic + Nuxt Watch-outs".
|
||||
- Output: `app/pages/reservations/edit/[id].vue` (import added)
|
||||
- Output: `CLAUDE.md` (new "Ionic + Nuxt Watch-outs" section under Routing)
|
||||
|
||||
2. **Made desktop schedule slots interactive** → previously desktop grid had no click handlers. Added same tappable logic as mobile: available slots → create flow; own booked slots → action sheet with Edit/Cancel.
|
||||
- Output: `app/pages/schedule.vue` (template changes in desktop grid)
|
||||
|
||||
3. **Added confirmation dialog before cancelling from schedule** → both mobile and desktop Cancel actions now show `alertController` confirmation before proceeding.
|
||||
- Output: `app/pages/schedule.vue` (`confirmCancelSlot()` wrapping `cancelSlot()`)
|
||||
|
||||
4. **Added admin interactivity on schedule** → admins can tap any booked slot (not just own). Action sheet header shows member name for admin context.
|
||||
- Output: `app/pages/schedule.vue` (`authStore.isAdmin` checks in tappable conditions and `handleSlotClick`)
|
||||
|
||||
5. **Added member names to schedule slots** → put `member_name` into `reservation_slots` view via LEFT JOIN on `members`. `security_invoker=false` means the JOIN bypasses RLS — no separate query needed, no RLS block for non-admins.
|
||||
- Output: `supabase/migrations/20260422000000_reservation_slots_add_user_id.sql`
|
||||
- Output: `app/types/supabase.ts` (added `user_id`, `member_name` to `reservation_slots` Row)
|
||||
- Output: `app/pages/schedule.vue` (replaced `getUserNameById` calls with `slot.memberName`)
|
||||
|
||||
6. **Fixed slot display** → desktop slots now show `HH:MM-HH:MM` on one line. All slots (available + booked, mobile + desktop) render a consistent 3-row structure (time, status, member) with `min-height` reserved for the member row so sizes are uniform.
|
||||
- Output: `app/pages/schedule.vue` (template restructure + CSS)
|
||||
|
||||
7. **Admin member selector on create reservation** → when admin, step 2 of create flow shows a Member dropdown (defaults to "Self (admin)"). Selected member passed as `target_user_id` to edge function.
|
||||
- Output: `app/pages/reservations/create.vue`
|
||||
|
||||
8. **Admin member selector on edit reservation** → when admin, edit page loads all members and shows a Member selector pre-populated from the reservation's `user_id`. Saved in update payload.
|
||||
- Output: `app/pages/reservations/edit/[id].vue`
|
||||
|
||||
9. **Edge function: admin target_user_id support** → accepts optional `target_user_id` in body. If caller is admin and field is set, uses it as the reservation owner. Admins bypass cert check, weekly limit, and weekend limit. Historical booking guard simplified (was duplicating the admin fetch). Overlap constraint still applies to all.
|
||||
- Output: `supabase/functions/create-reservation/index.ts`
|
||||
|
||||
10. **Documented user stories** → created `docs/planning/user-stories.md` with US-01–US-13 across four feature areas. Updated `docs/summaries/00-project-brief.md` with planned features table.
|
||||
- Output: `docs/planning/user-stories.md` (new file)
|
||||
- Output: `docs/summaries/00-project-brief.md` (planned features + open items)
|
||||
|
||||
---
|
||||
|
||||
## Exact State of Work in Progress
|
||||
|
||||
- All changes typecheck clean (`yarn typecheck` → no errors)
|
||||
- Migration `20260422000000` applied to local DB via `supabase db reset`
|
||||
- Migration NOT yet pushed to dev/prod Supabase — needs `supabase db push` or deploy pipeline
|
||||
- Edit page fix (import from `vue-router`) confirmed working conceptually; not browser-tested this session
|
||||
|
||||
---
|
||||
|
||||
## Decisions Made This Session
|
||||
|
||||
- **Import `useRoute`/`useRouter` from `vue-router` directly, never use Nuxt auto-import** BECAUSE Nuxt's auto-imported `useRoute()` always returns `params: {}` inside IonRouterOutlet — confirmed by official docs at ionic.nuxtjs.org/get-started/watch-outs and by console.log showing `params: {}` at runtime — STATUS: CONFIRMED. Apply to all future param-reading pages.
|
||||
|
||||
- **Put `member_name` in the view via JOIN rather than lazy-fetching via `getUserNameById`** BECAUSE `getUserNameById` relies on a members query that is blocked by RLS for non-admin users (returns null → "Unknown"). `security_invoker=false` on the view makes the JOIN run as owner, bypassing RLS — STATUS: CONFIRMED.
|
||||
|
||||
- **Admins bypass all booking limits and cert checks in the edge function** BECAUSE admin-created bookings are operational overrides, consistent with how `admin/reservations.vue` (direct insert) already worked — STATUS: CONFIRMED. Overlap constraint still applies to everyone.
|
||||
|
||||
- **Always render member name row in slot blocks (even if empty string)** BECAUSE rendering it conditionally causes slots to have different heights — STATUS: CONFIRMED.
|
||||
|
||||
---
|
||||
|
||||
## Key Numbers Generated or Discovered This Session
|
||||
|
||||
- `reservation_slots` view now has 7 columns: `id, boat_id, user_id, start_time, end_time, status, member_name`
|
||||
- US-12, US-13 added (member profiles) — total user stories now: 13
|
||||
- Migration sequence: `...000002_prevent_past_reservation_updates.sql` → `...20260422000000_reservation_slots_add_user_id.sql`
|
||||
|
||||
---
|
||||
|
||||
## Files Created or Modified
|
||||
|
||||
| File Path | Action | Description |
|
||||
|-----------|--------|-------------|
|
||||
| `supabase/migrations/20260422000000_reservation_slots_add_user_id.sql` | Created | Drops and recreates `reservation_slots` view with `user_id` and `member_name` (LEFT JOIN members) |
|
||||
| `app/types/supabase.ts` | Modified | Added `user_id: string` and `member_name: string \| null` to `reservation_slots` Row |
|
||||
| `app/pages/schedule.vue` | Modified | Desktop interactivity; admin access; member names; confirmation dialog; slot display fix |
|
||||
| `app/pages/reservations/edit/[id].vue` | Modified | Import `useRoute`/`useRouter` from `vue-router`; admin member selector |
|
||||
| `app/pages/reservations/create.vue` | Modified | Admin member selector (step 2); passes `target_user_id` to edge function |
|
||||
| `supabase/functions/create-reservation/index.ts` | Modified | `target_user_id` support; admin bypasses limits; deduped admin check |
|
||||
| `CLAUDE.md` | Modified | Added "Ionic + Nuxt Watch-outs" section (6 rules from official docs) |
|
||||
| `docs/planning/user-stories.md` | Created | US-01–US-13 across Open Reservations, Notifications, Check-out/in, Member Profiles |
|
||||
| `docs/summaries/00-project-brief.md` | Modified | Added planned features table linking to user stories |
|
||||
|
||||
---
|
||||
|
||||
## What the NEXT Session Should Do
|
||||
|
||||
1. **First**: Browser-test the edit page fix — navigate from home/schedule to an edit page and confirm reservation loads. Check console for any remaining `params: {}` warnings.
|
||||
2. **Then**: Push migration `20260422000000` to dev Supabase (`supabase db push --linked` or via deploy pipeline).
|
||||
3. **Consider**: Any other pages in the app that use `useRoute()` for params need the same `import { useRoute } from 'vue-router'` fix. Run a grep for auto-imported `useRoute` usage on param pages.
|
||||
4. **Consider next feature**: Open Reservations (US-01–US-07) or Member Profiles (US-12–US-13) — ask Patrick which to tackle.
|
||||
|
||||
---
|
||||
|
||||
## Open Questions Requiring User Input
|
||||
|
||||
- [ ] US-07: What constitutes a "non-member" on a reservation? (name-only entry, or guest account?) — impacts crew schema design
|
||||
- [ ] US-10: What fields are on the check-out/in forms? — impacts DB schema
|
||||
- [ ] US-13: Full list of member-controlled privacy fields (is phone in schema? any other fields?) — impacts members table migration
|
||||
- [ ] US-13: Privacy enforcement via RLS on `members`, or a separate `member_profiles` view? — impacts DB design
|
||||
- [ ] US-08: Discord webhook URL/channel — confirm stored in Vault at `kv/oys/`?
|
||||
|
||||
---
|
||||
|
||||
## Assumptions That Need Validation
|
||||
|
||||
- ASSUMED: `import { useRoute } from 'vue-router'` fixes params for ALL IonRouterOutlet param pages, not just the edit page — validate by testing at least one other param route if more are added.
|
||||
- ASSUMED: `security_invoker=false` on `reservation_slots` view is sufficient to expose member names to all authenticated users without violating privacy intent — validate with Patrick (member names may eventually be subject to US-13 privacy rules).
|
||||
|
||||
---
|
||||
|
||||
## Files to Load Next Session
|
||||
|
||||
- `docs/summaries/handoff-2026-04-22-schedule-admin-routing-fixes.md` — this file
|
||||
- `docs/summaries/00-project-brief.md` — project state and open items
|
||||
- `docs/planning/user-stories.md` — if working on any new feature
|
||||
- `app/pages/schedule.vue` — if continuing schedule work
|
||||
- `CLAUDE.md` — always (routing rules, data fetching pattern, Ionic watch-outs)
|
||||
Reference in New Issue
Block a user