✨ Finish event creation and editing flow

[Justber79]

Description

Finishes the dashboard event-management flow so coordinators can create, view, edit, and delete persisted events.
The calendar now displays real event data and provides a clearer overview of upcoming and past events. The existing three-step creation design is preserved while adding the missing event fields and backend integration.

Related Issues

Closes #945

Changes

• Connect the event flow to the real GET, POST, PATCH, and DELETE event endpoints.
• Display upcoming and past events fetched from the backend.
• Add event markers to the calendar.
• Allow selecting a calendar date to prefill the creation form.
• Add start date, end date, start time, and end time fields.
• Add the registration-link field.
• Add required address-field validation.
• Add a 512-character description limit matching the backend constraint.
• Add an edit route and prefill the form with the selected event’s saved values.
• Add event deletion with a confirmation dialog.
• Add English and German translations for the new UI.
• Update the event API types through the published need4deed-sdk package.

Screenshots / Demos

Before

After

Events dashboard — German

Events dashboard and event flow — English

Testing

• yarn typecheck — passed
• yarn lint — passed with four pre-existing, unrelated React Hook warnings
• git diff --check — passed
• Manually tested creating, displaying, editing, and deleting events.
• Manually tested calendar navigation and event date markers.
• Manually checked the English and German versions.

Checklist

• WITHIN THE SCOPE OF AN ISSUE; No unnecessary files included
• Tests added/updated — no automated tests added; flow tested manually
• Documentation updated — not required
• CI passes — pending PR checks

[arturasmckwcz]

Follow-up on #945: instructions for making the calendar reusable

Functionally this PR already covers the ask (fetch/create/edit/delete events, month grid, upcoming/past lists). What's still needed is a refactor so CalendarContent.tsx (currently ~480 lines, everything inline) stops being a monolith. Whoever picks this up (including a coding assistant) should treat it as a follow-up to this PR, working from what's already merged/open here.

The page (CalendarContent.tsx) should end up doing only 3 things:

1. Call a hook that returns the events for the given month.
2. Render the "Create an event" CTA.
3. Render a reusable Calendar component.

1. Consolidate the data logic into a hook

src/hooks/useEvents.ts already has useEvents, useCreateEvent, useUpdateEvent(id), useDeleteEvent. Build on top of these rather than replacing them:

• Add useEvent(id) for single-event fetch. CreateEvent.tsx currently derives the editing event by events.find(e => e.id === eventId) off the full useEvents() list (see src/components/Dashboard/Calendar/CreateEvent/CreateEvent.tsx) — formalize that into its own hook so it's not duplicated wherever a single event is needed. Reusing the cached list via select is fine; it doesn't need a dedicated network call unless we want to avoid loading the whole list just to open one event.
• Add an orchestration hook (e.g. useCalendar() in src/hooks/useCalendar.ts) that wraps the above and owns everything CalendarContent.tsx currently hand-rolls inline:
  • month state (monthDate, setMonthDate, prev/next)
  • upcoming / past derivation (currently the events.filter(...) / .reverse() lines directly in the component)
  • the day-click handler (currently clickDay) — on click, decide "scroll to that day's items" vs. "fire the empty-date callback"
  • edit/delete trigger functions and the delete-confirmation dialog state (currently local useState<ApiEventN4DGetList | null> for deleting)
• The events fetch itself doesn't need real month filtering on this pass — apiPathEvent returns the full list and the dataset is small; keep loading everything once and filter by month client-side inside the hook. Don't add a backend query param for this unless it's already in the SDK contract.

2. Split into components

Two new pieces, both currently inlined in CalendarContent.tsx:

(a) Reusable Calendar component — new folder, e.g. src/components/Dashboard/Calendar/Calendar/, composed of 3 widgets:

• CalendarGrid — the month grid (currently the cells() helper + Days/Day/Dot styled components)
• UpcomingEvents — the upcoming list (currently the upcoming.map(EventCard...) block)
• PastEvents — the collapsible past list (currently the Past/PastToggle/PastRow block)

The EventCard component (currently defined inline in CalendarContent.tsx) should move into this folder too and support both a "card" and a "bar" rendering variant, since past events currently render as a plain PastRow bar while upcoming events render as a full Card — make that an explicit prop rather than two separate hand-written layouts.

(b) "Create an event" CTA — extract the Button + create() navigation call into its own small component (e.g. CreateEventCta.tsx) so it's not tangled with the rest of the page.

3. Calendar component contract

• Props: the month's events, the current month/navigation state, and a callback — something like onEmptyDateClick(date: Date) — for what to do when an empty grid date is clicked.
• Default behavior (no override needed for the dashboard use case):
  • List all of the month's events across the two widgets: upcoming and past.
  • Each list item can render as a card or a bar (see variant note above).
  • Clicking a grid date with events scrolls to that day's items; clicking an empty date fires onEmptyDateClick. Note: the current clickDay implementation only scrolls to the first event matching that date (events.find(...) + getElementById('event-${event.id}')) — since a day can have multiple events, this should scroll to/highlight the whole group for that day, not just one.
  • The grid should stay visible at all times when there's enough room — it's currently in a Grid/aside layout that already keeps it beside the list, but check that behavior holds (e.g. position: sticky on the aside) once the list is long enough to scroll.

No SDK or backend changes needed for this pass — it's a pure frontend refactor of code that's already functionally complete in this PR.

[nadavosa]

Reviewed the diff and checked it out locally. tsc --noEmit and yarn lint both pass clean on this branch (only the same 4 pre-existing, unrelated hook warnings you already called out). Note GitHub hasn't actually run CI on this PR yet, it's a fork PR and no check runs exist for the head commit yet (probably needs a maintainer to approve the workflow run), so "CI passes" isn't confirmed from GitHub's side yet, just from my local run.

Found a few real issues worth addressing before merge:

1. Event type is hardcoded to WORKSHOP for every event. toPayload() in CreateEvent.tsx always sets type: EventN4DType.WORKSHOP, but the SDK enum has two values (PARTY, WORKSHOP) and there's no UI to choose. Every event a coordinator creates through this flow, including a purely social one, gets tagged as a workshop. Was this intentional (e.g. "party" isn't used yet), or should there be a type selector in the form?

2. Events only get a translation in the coordinator's current UI language. toPayload() submits a single-element translations array using i18n.language. Since the public site is bilingual and translations is a required array (per ApiEventN4DCreate), an event created by a German-speaking coordinator has no English translation record at all, and vice versa. Non-matching-locale visitors to the public event page would presumably see nothing (or a broken fallback) for that event. This seems like a real gap for a bilingual site rather than an edge case.

3. Multi-day events aren't reflected on the calendar past their start day. eventDays (for the dot markers) and clickDay (click-to-scroll-to-event) in CalendarContent.tsx both key only on event.date, never event.dateEnd. Since the date/time step explicitly supports a different end date (with end > start validation), a coordinator can create a multi-day event, but the calendar only marks its first day. Clicking the event's other days (including its own end day) shows no marker and offers "create event" there instead, since nothing flags that day as occupied.

4. Multi-day event card display reads as a same-day range. EventCard's range() helper builds the date from event.date but appends endTime from event.dateEnd regardless of whether they're the same calendar day, e.g. a Friday 18:00 → Saturday 09:00 event renders as "Friday, ... · 18:00–09:00", which reads like an invalid same-day range rather than a two-day span.

5. Minor: /dashboard/calendar/[id]/edit/page.tsx does Number(id), if the id in the URL isn't numeric this becomes NaN, which is falsy, so CreateEvent silently falls into "create new event" mode instead of showing an error for a malformed edit URL. Low severity, just flagging.

None of these are typos or crashes, the flow works for the straightforward same-day, single-language case shown in the screenshots, but 1-3 look like they'd affect real usage once coordinators create multi-day or non-English-only events.

[Justber79]

@arturasmckwcz @nadavosa Thank you both for reviewing the PR and for the detailed feedback. I’ve pushed commit daec62e5 addressing your comments.

For Arturas’s refactor request:

• CalendarContent.tsx now only calls useCalendar(), renders CreateEventCta, and renders the reusable Calendar.
• The calendar is split into CalendarGrid, UpcomingEvents, PastEvents, and EventCard with card/bar variants.
• useEvent(id) and useCalendar() now own the relevant data and orchestration logic.
• Occupied dates scroll to and highlight the complete date group; empty dates open the creation flow with the date prefilled.
• The calendar remains sticky on desktop.

For Nadav’s findings:

• Multi-day events mark every covered day, including across months.
• Multi-day ranges display both dates correctly.
• Malformed edit URLs show Not Found.
• Event type is now selectable using the existing SDK EventN4DType values: WORKSHOP and PARTY. The selected type is saved and restored during editing.

One question remains about translations: should coordinators enter both English and German title/description, or should the public event pages rely on the backend fallback when only one translation exists?

Updated calendar

Event type selector

Please let me know if I should make any further changes to PR #952.

[nadavosa]

Re-reviewed after the latest push (daec62e). Pulled the branch, tsc --noEmit and yarn lint both pass, and CI is green now too.

All previously flagged issues are genuinely fixed, verified in code, not just claimed:

1. Event type — StepTitle.tsx now has a real <select> with both WORKSHOP and PARTY (both translation keys present in en/de), wired through formData.type into toPayload(). Confirmed.
2. Multi-day calendar marking — utils/calendar.ts's eventDateKeys() now expands the full date→dateEnd range, and CalendarGrid marks every day in that range (with a count badge, nice touch). Confirmed.
3. Multi-day range display — eventDateRange() now branches on dateKey(start) === dateKey(end), showing "start · time – end date · time" when they differ instead of mixing the two into a same-day-looking range. Confirmed.
4. Malformed edit URL — [id]/edit/page.tsx now validates Number.isInteger(eventId) && eventId > 0 and calls notFound() otherwise, instead of silently falling into create-mode. Confirmed.

On the open translation question: checked the be DTO (dto-event.ts) — resolveTranslation() already falls back to whichever translation exists when the requested language's isn't there (event.eventTranslation?.[0]), per the be#903 comment in that file. So relying on the backend fallback is fine, coordinators don't need to enter both languages for this to work; the event just won't be localized for the other language until someone adds that translation. No further fe change needed for that.

On the refactor (Arturas's ask): CalendarContent.tsx is now a clean 60-line orchestrator (hook + CTA + Calendar), and the day-click/highlight logic in useCalendar.ts + groupEventsByDate correctly handles the "highlight the whole day's group, not just one event" case, including for multi-day events (clicking a non-start day of a multi-day event still resolves and highlights the correct group). Nice work, this looks solid to me.

No further blockers from my side.

[arturasmckwcz]

Re-review findings (automated).

[arturasmckwcz]

toPayload() hardcodes active: true on every submit (CONFIRMED)

BE's PATCH /event/:id treats active as a genuine partial-update field (omitted = unchanged, via TypeORM's undefined-skips-column behavior in write-event.ts). EventCard.tsx even renders a Published/Draft badge from event.active, implying drafts are real. But toPayload() is shared by create and edit and always sends active: true with no UI control — a coordinator who opens a draft event just to fix a typo and saves will unintentionally publish it, with no way to un-publish through this flow.

[arturasmckwcz]

Edit form omits fields BE treats as explicit-clear (CONFIRMED)

toPayload()'s translations entry omits subTitle, locationComment, additionalTitle, additionalInfo, outro and followUpText. be/src/server/utils/data/write-event.ts's translationFields() sets each of these to t.field ?? null on save — deliberate per its own comment ("leaving these as undefined would silently keep the old value instead of clearing it"). editingEvent does carry subTitle/locationComment/additionalTitle/additionalInfo, but the form never reads or re-sends them, so any event with these fields set gets wiped to null the moment it's edited through this form.

[arturasmckwcz]

Edit under mismatched UI language duplicates translation row (CONFIRMED)

useEvents() calls GET /event with no language param, so BE resolves under default Lang.DE; dto-event.ts's resolveTranslation() falls back to eventTranslation[0] (any language) when no DE row exists. If a German-UI coordinator edits an event whose only translation is English, the form displays that English content, but toPayload() tags the submission language: Lang.DE. BE's per-language upsert then inserts a new DE row containing the English text, leaving the original English translation untouched and duplicated under the wrong language.

[arturasmckwcz]

Blank page on missing/failed event edit, no way back (CONFIRMED)

Both the "still loading" branch (here, line 150) and the "event not found" branch (line 156) render an identical empty <PageContent /> with no message and no way back. Navigating to /calendar/<id>/edit for an id that never resolves (stale link, event deleted by someone else, or a fetch failure) leaves the user staring at a permanently blank page — no error text, no retry, no link back to the calendar.

[arturasmckwcz]

Create-event CTA lost date prefill from selected day (CONFIRMED)

<CreateEventCta onCreate={() => calendar.createEvent()} /> always calls createEvent with no date argument. selectDate() only auto-navigates when the clicked day has no events; a day that already has events just gets highlighted/scrolled. A coordinator who selects such a day then clicks the top button, expecting the new event prefilled with that date, silently loses the prefill — a regression vs. the old handleCreateEvent this replaced.

[arturasmckwcz]

Non-matching address format blocks edit flow (PLAUSIBLE)

parseAddress()'s regex only matches a strict "Street Number, PPPPP…" shape. BE's address column has no format constraint beyond minLength: 1. An address that doesn't match the pattern falls back to {street: address, houseNumber: '', postcode: ''}; step 2's isNextEnabled requires houseNumber/postcode non-empty, so the coordinator gets stuck on step 2 with no explanation.

[arturasmckwcz]

No fallback for empty/invalid linkRSVP href (PLAUSIBLE)

The registration link renders <a href={event.linkRSVP}> with no fallback. BE's schema only requires linkRSVP to be a string (no format/minLength check). An event created outside this new FE flow with an empty linkRSVP makes "Open registration link" just reload the current page.

[arturasmckwcz]

Impure setState side effect inside functional updater (PLAUSIBLE)

setShowPast is invoked as a side effect inside the setMonthDate functional updater, which React requires to be pure. React can invoke a functional updater more than once (Strict Mode double-invoke, or future concurrent-rendering paths); each extra invocation re-fires setShowPast as an unintended side effect. Idempotent today, but fragile and couples unrelated state through hidden call order.

[arturasmckwcz]

useEvent fetches full list instead of single resource (CONFIRMED)

useGetVolunteer/useGetOpportunity both fetch one resource by id. useEvent instead pulls the full list via useEvents() (ApiEventN4DGetList shape, which lacks hostName/time/outro/followUpText/followUpLink/locationLink) and finds by id client-side, so the edit form can never read or preserve those fields for an event that has them — compounding the translation-field data loss on save (see the comment on line 115).

[arturasmckwcz]

useDeleteEvent hand-rolls axios instead of useMutationQuery (CONFIRMED)

useDeleteOpportunity/useDeleteAgent both go through useMutationQuery({apiPath, method: 'delete', ...}) with no direct axios import. useDeleteEvent imports axios directly instead, violating fe/CLAUDE.md's "use these hooks, don't call axios directly" and shared-rules.md's "reuse before you create," for no functional reason since useMutationQuery already supports this case.

[Justber79]

@nadavosa @arturasmckwcz Thanks for the re-review. I addressed the FE-actionable findings in commit 4230f4ed:

• Editing now preserves the existing active status, so saving a draft typo does not publish it.
• Existing optional translation fields returned by the API (subTitle, locationComment, additionalTitle, and additionalInfo) are re-sent during edits.
• Loading and failed event edits now show a status/error message and a Back to calendar action.
• The selected calendar date is preserved when opening Create event.
• Non-standard addresses no longer trap the user in step 2.
• Empty or invalid registration links fall back to translated text instead of rendering a broken link.
• Calendar month changes no longer perform state updates inside a functional updater.
• Event deletion now uses the shared useMutationQuery hook.

I verified yarn typecheck, yarn lint, and git diff --check, and browser-tested creation, calendar markers, editing, invalid edit URLs, delete confirmation, deletion, and the empty-calendar state.

The remaining data-preservation items require backend support:

1. The current GET /event list response does not include full-detail translation fields such as outro and followUpText, so FE cannot preserve those values when editing.
2. There is still no GET /event/:id; useEvent(id) therefore reuses the cached list, which is the only currently available contract.
3. When the backend falls back to another language, the response does not identify the language that was actually returned. FE therefore cannot safely prevent an English fallback from being saved as a new German translation.

To complete those items, BE would need either a GET /event/:id response containing the complete event details and translation language metadata, or an equivalent list response that includes all translations and the resolved language. useEvents() already passes the current UI language automatically through useGetQuery.

[Justber79]

@nadavosa @arturasmckwcz Follow-up fix pushed in b32b9ea:

• Structural event edits now omit translations, so the backend preserves all existing translation fields instead of replacing them from the list response.
• Translations are included only when the title or description is intentionally changed.
• An unchanged legacy empty/invalid registration-link value no longer blocks unrelated edits; newly entered values still require a valid HTTP(S) URL.

Verified with yarn typecheck, yarn lint (four pre-existing hook warnings), yarn build, and git diff --check.

One backend-dependent limitation remains: when the title or description is edited, the frontend cannot determine whether GET /event returned the requested language or a fallback. Fully resolving this requires the API to return the resolved language and complete event/translation details, ideally through GET /event/:id.

[Justber79]

Fixed and pushed in commit 5549f17.

The event-type dropdown now:

• Opens directly beneath the field at every viewport size.
• Matches the field width.
• Supports mouse selection, arrow keys, Enter/Space, Escape, and outside-click closing.
• Preserves focus after selection.

Type-checking, linting, and the production build pass.