[edwh]

What the prototype does now

Prototype (RESDISCO-248), not intended to merge as-is.

• New Upcoming events section on the network page, between "events requiring moderation" and the groups map.
• List | Calendar toggle (choice remembered in localStorage) and a "Subscribe to calendar" button for the whole network (reuses CalendarAddModal with /calendar/network/{id}).
• List view: events grouped under month headings, soonest first; date block, venue/title, times (in the event's own timezone), group name, and markers for online, cancelled, unapproved group and archived group; each row links to the event.
• Calendar view: Monday-first month grid with prev/next, per-day chips (time + group), aria-label per cell, count dot only on small screens. Events on unapproved or archived groups are dashed chips; the chip's tooltip says why.
• Cancelled events are struck through (not greyed out), with a "Cancelled" badge in the list.
• Past events are hidden until "Include past events" is ticked.
• Filters: group multi-select, date range (next 7 days / 30 days / custom), "include past events", "Clear filters", "N events" count.
• Unapproved and archived groups: coordinators of the network and admins also see events on groups waiting for approval (a prompt to approve the group) and on archived groups (only past events, so they show once past events are included). Nobody else does.
• API GET /api/v2/networks/{id}/events:
  • start/end return events overlapping the window.
  • By default only approved events on approved, active groups. include_unapproved=1 adds unapproved and archived groups, but only when the api_token belongs to an admin or a coordinator of that network; otherwise it is ignored.
  • PartySummary has cancelled; GroupSummary has approved (alongside the existing archived_at).
• en / fr / fr-BE strings under networks.events.*.
• Tests: Jest (networkEventsUtil, NetworkEvents, NetworkPage); PHPUnit testNetworkEventsOverlapArchivedAndCancelled and testNetworkEventsIncludeUnapprovedForCoordinators (guest, host, another network's coordinator, this network's coordinator, admin).

Out of scope: clash detection (better as a warning when a group creates an event on a busy day, a separate feature), map view, URL-synced filters, pagination. The component fetches directly with axios rather than via the events Vuex store (the store's old-format conversion expects stats the summary feed does not carry).

Screenshots

List, upcoming only (the default):

List with past events, showing the archived group's past event:

Calendar, and the next month with the unapproved group's event as a dashed chip:

Decisions (from the call with Edward and Neil)

• Cancelled events are shown struck through, not greyed out.
• Past events are hidden by default; the "Include past events" checkbox in the filter bar shows them.
• No clash badge or clash detection. A same-day-nearby warning when a host creates an event is a separate future feature.
• Anyone who can open the network page sees this section. It has no actions beyond opening an event and subscribing to the calendar. Who can open the page is Prototype: network page visible to group organisers (RESDISCO-249) #945 (hosts of groups in the network); on this branch alone only coordinators and admins can. The events API is the server-side gate: include_unapproved is ignored for guests, hosts, volunteers and other networks' coordinators (tested).
• Subscribe to calendar for the whole network: the existing /calendar/network/{id} iCal feed, via the "Subscribe to calendar" button.
• Events on unapproved or archived groups are visible to the network's coordinators and admins only, with a badge showing the group's status. Archived groups' events appear once past events are shown.
• No map view.

Notes

• Neil's follow-up: the page is getting busy and may need rearranging, and the same list/calendar could replace the tabs on /party.
• SonarCloud's duplication gate fails on the en/fr/fr-BE networks.php blocks, which are near-identical by nature. Excluding lang/** from duplication in SonarCloud's project settings would fix it; that setting is only in the SonarCloud UI.

[github-actions]

Preview: https://restarters-pr-944.fly.dev

✅ Ready - restore and migrations succeeded.

• Branch is 13 commit(s) behind develop (0 touching migrations); the preview is built from the merge with current develop.

• Password-protected test environment (usual dev gate password); commit 11141d42a34135f9636cdc98d03e3214987bc313 merged with develop.

• If you see a "warming up" page, give it a few minutes - it refreshes itself.

• The preview database is refreshed on every deploy and may reset at any time; anything you create here is disposable.

• Emails go to shared Mailpit, never to real recipients. Image uploads are disabled.

• The app suspends when idle; the first request after a pause can take a moment.

[ngm]

@edwh In addition to our run through of the questions in our catchup - some additional thoughts.

From taking a quick look at the preview, I love it as a concept already. Immediate utility to network coordinators. The page becomes a bit cluttered, so some considered re-jigging of the page might be needed.

It now strikes me that perhaps more immediately relevant than #945 as a follow up to this is adding a similar events list / calendar to the existing events page (/party).

If we did, the odd tabbing interface of /party could probably be dropped. You'd just have the list / calendar, and:

• past events becomes a filter toggle
• show other events nearby would likely be a filter toggle
• show all events could be a filter toggle (though debatable how useful to the average user - is it more of an admin function?)

Though an open question is the map question. It's a bit less clear how that would work here. Show other events nearby without a map means an artificial definition of what 'nearby' means. But syncing a map / list / calendar based on where you're looking at on the map in the same way we do on the groups page might not quite work either. Worth playing with and thinking about more.

[sonarqubecloud]

Quality Gate failed

Failed conditions
7.2% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud