Edit an event's repeat rule (both surfaces) #77

New issue

Closed

opened 2026-08-14 17:39:55 +00:00 by nalum · 1 comment

nalum commented

2026-08-14 17:39:55 +00:00

Owner

Summary

Let a member edit a recurring event's repeat rule, on both surfaces. Today the recurrence is fixed at creation: the event-edit flow deliberately hides the repeat control, so name, time, guests and description can change but the rule cannot.

Background

UpdateEventRequest carries no repeat field, and the edit form (web NewEventForm, Android NewEventSheet) hides the repeat editor when edit is set. Changing a rule mid-series is not a plain field update — it re-derives every future occurrence — so it was left out of the event-editing work (#61) on purpose.

The hard part — this-one-vs-series semantics for a rule change

A rule change only makes sense at the series level, and it interacts with any one-off edits or cancellations already made to occurrences. Decide and document:

Does changing the rule keep or discard existing per-occurrence overrides and tombstones (split children, cancelled slots)?
Does the new rule apply from the series start, or from "this occurrence forward" (split the series at the current date, old rule before, new rule after)?
Is the repeat until date editable on its own (the common, low-risk case) separately from the full rule?

A reasonable first cut: allow editing the rule and the until date for the whole series from the series edit, keeping it simple, and defer "change from here forward" if it proves fiddly.

Scope

Server: extend EventService.Update (or a dedicated RPC) to accept a repeat rule, or a new SetRepeat-style event RPC. Needs a PermissionMatrix entry and likely an ADR (schema/behavior change to recurrence).
Web: show the RepeatEditor in the event edit form for a series, wired to the new capability.
Android: same, showing RepeatRuleEditor in the edit sheet.
Reuse the existing SplitOccurrence machinery if "from here forward" is chosen.

Definition of done

A member can change a recurring event's rule (at least its until date) from the series edit, on web and Android.
The occurrence-vs-series behavior for a rule change is documented (ADR if the schema or recurrence semantics change).
make check passes; verified on both surfaces against the live deploy.

### Summary Let a member edit a recurring event's repeat rule, on both surfaces. Today the recurrence is fixed at creation: the event-edit flow deliberately hides the repeat control, so name, time, guests and description can change but the rule cannot. ### Background `UpdateEventRequest` carries no repeat field, and the edit form (web `NewEventForm`, Android `NewEventSheet`) hides the repeat editor when `edit` is set. Changing a rule mid-series is not a plain field update — it re-derives every future occurrence — so it was left out of the event-editing work (#61) on purpose. ### The hard part — this-one-vs-series semantics for a rule change A rule change only makes sense at the series level, and it interacts with any one-off edits or cancellations already made to occurrences. Decide and document: - Does changing the rule keep or discard existing per-occurrence overrides and tombstones (split children, cancelled slots)? - Does the new rule apply from the series start, or from "this occurrence forward" (split the series at the current date, old rule before, new rule after)? - Is the repeat `until` date editable on its own (the common, low-risk case) separately from the full rule? A reasonable first cut: allow editing the rule and the `until` date for the whole series from the series edit, keeping it simple, and defer "change from here forward" if it proves fiddly. ### Scope - Server: extend `EventService.Update` (or a dedicated RPC) to accept a repeat rule, or a new `SetRepeat`-style event RPC. Needs a `PermissionMatrix` entry and likely an ADR (schema/behavior change to recurrence). - Web: show the `RepeatEditor` in the event edit form for a series, wired to the new capability. - Android: same, showing `RepeatRuleEditor` in the edit sheet. - Reuse the existing `SplitOccurrence` machinery if "from here forward" is chosen. ### Definition of done - A member can change a recurring event's rule (at least its `until` date) from the series edit, on web and Android. - The occurrence-vs-series behavior for a rule change is documented (ADR if the schema or recurrence semantics change). - `make check` passes; verified on both surfaces against the live deploy.

nalum added the

enhancement

android

web

labels

2026-08-14 17:39:55 +00:00

nalum added this to the (deleted) project

2026-08-14 21:50:59 +00:00

nalum referenced this issue

2026-08-16 14:27:32 +00:00

plan: open-backlog execution order (2026-08-16) #100

nalum commented

2026-08-16 14:37:58 +00:00

Author

Owner

Decisions (2026-08-16): first cut is the full rule editable for the whole series (rule + until; the new rule re-derives the series from its start; "from here forward" deferred). On a rule change, per-occurrence edits and cancelled slots are kept where their dates survive under the new rule; orphaned ones are dropped. ADR to document both.

Decisions (2026-08-16): first cut is the **full rule editable for the whole series** (rule + until; the new rule re-derives the series from its start; "from here forward" deferred). On a rule change, per-occurrence edits and cancelled slots are **kept where their dates survive** under the new rule; orphaned ones are dropped. ADR to document both.

nalum added the

adr

label

2026-08-16 14:41:12 +00:00

nalum added this to the Nudges, Parity & Repeats milestone

2026-08-16 14:41:15 +00:00

nalum added reference main

2026-08-16 14:43:35 +00:00

nalum changed reference from ~~main~~ to v1.5.0

2026-08-16 14:43:57 +00:00

nalum referenced this issue from a commit

2026-08-16 15:45:51 +00:00