feat(dashboard): a guests page for an event

[harshtandiya]

Stacked on #355. The event workspace's second section: who is coming.

What this adds

Guests replaces Attendees in the event sidebar, and the destination is a page rather than the placeholder.

A glance at the turnout — the number registered, and whether registrations are still open. Whether they are closed is the booking flow's own rule (are_registrations_closed), reused rather than restated: an explicit cutoff if the event sets one, otherwise the end of the event.

The guest list — one row per submitted ticket, showing avatar, name, email beside the name, the add-ons that ticket holds as badges, and its ticket type. Searchable by name or email, filtered over the list already loaded so a keystroke costs nothing.

Only submitted tickets count. A draft belongs to a booking still being paid for, not somebody coming.

API

Endpoint	Method	Returns
buzz.api.events.get_event_guests	GET	Total, whether registrations are closed, and every guest with their add-ons.

Read access is the bar, not write — the list shows the team what the doctype already shows it.

Add-ons live in a child table that a plain list query cannot reach, which is what this endpoint is for. Two details worth knowing, both caught by tests:

• Event Ticket Type and Ticket Add-on are autonamed, so the link value alone is a docname nobody recognises (18213). Both are resolved to their titles, one batched query each.
• An autonamed doctype comes back from get_all with integer names while every link to it travels as a string, so the title map is keyed by str(name) — without that it silently never matches.

Considered and dropped

A capacity bar, as on the reference design. create_event gives every event a published ticket type with no limit, so capacity resolved to "uncapped" on essentially every event and the bar would never have drawn. Left out rather than shipped as decoration.

Tests

• buzz.api.events.test_events — 37 pass, 8 new for get_event_guests: the count and list, a draft ticket excluded, add-ons carried through, the ticket type named rather than numbered, an empty event, registrations open and closed, a non-member refused, an unknown event.
• e2e/tests/manage-event.spec.ts — 14 pass, including the guest list (count matches row count, rows carry an email, the badge is not a bare number) and search narrowing to one row and back.

Known, not addressed here

One row per ticket, so somebody who booked six tickets under one name appears six times. Grouping by person is a separate decision.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

The PR adds an event guest-management page backed by a read-authorized API for submitted tickets.

• Adds guest totals, registration status, ticket types, and add-on data.
• Adds client-side guest search and event-workspace navigation.
• Reuses a shared event page header across the details and guests sections.

Confidence Score: 4/5

The PR is not yet safe to merge because read-only team members still receive write-protected event metadata on the guest page, producing an incorrect breadcrumb.

The previously reported access mismatch remains: the guest API permits team read access, but the page separately invokes get_event, whose service requires write access, so read-only viewers cannot obtain the event title.

Files Needing Attention: dashboard/src/pages/manage/events/EventGuests.vue, dashboard/src/data/events.ts

Important Files Changed

Filename	Overview
buzz/api/events/services.py	Adds the read-authorized guest-list service, submitted-ticket projection, title resolution, and registration-status calculation.
dashboard/src/pages/manage/events/EventGuests.vue	Adds the guest summary, searchable list, and shared event header integration.
dashboard/src/components/dashboard/events/EventGuestItem.vue	Renders each submitted ticket’s guest identity, add-ons, and ticket type.
dashboard/src/router.ts	Registers the guest page as a dedicated event-workspace route.
e2e/tests/manage-event.spec.ts	Covers guest navigation, list totals, labels, registration status, and client-side search.

_{Reviews (5): Last reviewed commit: "feat(dashboard): a glance at the turnout..." | Re-trigger Greptile}

[greptile-apps]

Write-only metadata breaks read access

When a Viewer or another read-only team member opens this page, eventDetail(eventId) invokes the write-protected event-detail API even though the guest endpoint permits read access, causing that metadata request to be rejected and the breadcrumb to display the generic “Event” fallback instead of the event title.

Prompt To Fix With AI

This is a comment left during a code review.
Path: dashboard/src/pages/manage/events/EventGuests.vue
Line: 12

Comment:
**Write-only metadata breaks read access**

When a Viewer or another read-only team member opens this page, `eventDetail(eventId)` invokes the write-protected event-detail API even though the guest endpoint permits read access, causing that metadata request to be rejected and the breadcrumb to display the generic “Event” fallback instead of the event title.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[github-actions]

❌ UI Demo Check failed

This pull request changes the UI (8 file(s) under dashboard/src/),
but the description has no screenshot or demo. Reviewers should be able to see the
change without checking out the branch.

🛠️ How to fix

• Edit the description and drag a screenshot or a short screen recording into it.
  Before/after images are ideal for visual tweaks.
• Or apply the skip-demo label if a visual makes no sense here
  (pure refactor, copy change, dependency bump).

Either one re-runs this check automatically.