Open Quorum on a filtered list of upcoming tests #54

Open
opened 2026-11-01 20:12:15 +00:00 by viacheslavshuka · 0 comments

Outcome

The first screen after completed login should make upcoming tests available without loading the full calendar. Build the lightweight list and its range-limited discovery query.

Acceptance criteria

  • Completed login opens an upcoming-session list. Basic participation navigation works before the calendar implementation loads.
  • Users can filter by date range, game format, available places, organizer, and fit to personal availability. Provide joined and organized views.
  • Availability filtering is optional for manual browsing. The fit filter requires the whole expected interval to fit effective availability.
  • Normal discovery excludes sessions matching ignored organizers. Show all tests includes them without removing ignores. Existing commitments stay visible in their own views.
  • Full sessions remain visible unless the user selects the available-places filter. Reserved places consume capacity. Tentative registrations do not.
  • Display Registration closed separately from Full. A closed or started test does not appear to accept new registrations because a cached capacity count has room.
  • Published tests are available to completed accounts. Private drafts remain limited to their authorized viewers. No private or unlisted published mode is added.
  • List responses reveal only permitted data. Pending-request and waiting-list identities and protected meeting links do not leak through cards or API fields.
  • Start and estimated end use the saved timezone with explicit dates and offsets. Loading, empty, and failed-query states remain distinguishable.
  • Queries limit the requested date range and result loading. They do not download the complete session history on entry.

Validation design

Use fixture sessions that differ in one filter dimension and assert exact included IDs. Include a reservation that fills the last place and a tentative tester that does not. Verify that an ignored existing commitment remains accessible. A production-browser test must detect calendar code loading before the user opens it and protected data leaking into list payloads.

Dependencies

## Outcome The first screen after completed login should make upcoming tests available without loading the full calendar. Build the lightweight list and its range-limited discovery query. ## Acceptance criteria - Completed login opens an upcoming-session list. Basic participation navigation works before the calendar implementation loads. - Users can filter by date range, game format, available places, organizer, and fit to personal availability. Provide joined and organized views. - Availability filtering is optional for manual browsing. The fit filter requires the whole expected interval to fit effective availability. - Normal discovery excludes sessions matching ignored organizers. Show all tests includes them without removing ignores. Existing commitments stay visible in their own views. - Full sessions remain visible unless the user selects the available-places filter. Reserved places consume capacity. Tentative registrations do not. - Display Registration closed separately from Full. A closed or started test does not appear to accept new registrations because a cached capacity count has room. - Published tests are available to completed accounts. Private drafts remain limited to their authorized viewers. No private or unlisted published mode is added. - List responses reveal only permitted data. Pending-request and waiting-list identities and protected meeting links do not leak through cards or API fields. - Start and estimated end use the saved timezone with explicit dates and offsets. Loading, empty, and failed-query states remain distinguishable. - Queries limit the requested date range and result loading. They do not download the complete session history on entry. ## Validation design Use fixture sessions that differ in one filter dimension and assert exact included IDs. Include a reservation that fills the last place and a tentative tester that does not. Verify that an ignored existing commitment remains accessible. A production-browser test must detect calendar code loading before the user opens it and protected data leaking into list payloads. ## Dependencies - [#44: Create private test drafts and publish complete announcements](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/44). Supplies published tests and viewer-safe details. - [#52: Register individual testers with approval, tentative status, and capacity checks](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/52). Supplies registration occupancy and personal participation data. - [#20: Display dates and deadlines in each user's saved timezone](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/20). Supplies recipient-timezone rendering. - [#28: Edit recurring availability with date overrides and overnight slots](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/28). Supplies complete-interval availability matching. - [#21: Let testers hide ignored organizers from ordinary discovery](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/21). Supplies organizer-ignore matching. - [#7: Create the React application with locked frontend tooling](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/7). Supplies localized routing and typed API access. ## Related work - [#59: Browse tests in month, week, and agenda views](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/59) - [#24: Keep browser data useful during slow or lost connections](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/24)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
viacheslavshuka/quorum#54
No description provided.