Calendar: edit and delete a single occurrence

Closes #132.

Stalwart 0.16.20 accepts a synthetic id on `CalendarEvent/set`, writing a
`recurrenceOverrides` entry rather than touching the series, so editing
one date of a recurring event is now something the server does and this
does too.

Editing asks the scope *before* the form opens, because it decides which
event the form is even about: a form populated from the master shows the
series' start date, so editing Wednesday's standup would have offered to
move Monday's. Deleting asks in place of the old confirm.

The patch is narrowed rather than posted hopefully. 0.16.20 sorts
per-occurrence properties into three groups and only one is honest: ten
are refused with `invalidProperties`, twelve more are dropped from the
patch while the response still reports success, and the rest are applied.
That silent middle group is how #26 reached a live server - a successful
response is not evidence anything was written - so `occurrencePatch`
throws on the first group, reports the second to the caller, and the
editor leaves out the five it always sends. A patch that would be
entirely dropped is not sent at all.

The refusal for an occurrence of a this-and-future change offers the
series instead of a bare error toast. Nothing here writes one of those,
but an event synced from another client can carry one.

Two things the scope prompt cost, both worth knowing. A dialog is queued
in a store the moment it is asked for, so it outlives the effect that
asked: without a ref guard a remount queues a second prompt the first
answer cannot retract. And gating the *answer* on the effect's cleanup
flag is worse - StrictMode runs mount, cleanup, mount, so the flag is
already set by the time anyone clicks and the editor never opens.

The mock expands recurrences for the first time, which is what makes any
of this developable. It hands out synthetic ids for everything including
one-offs, gives occurrences a `recurrenceId` and no rule, and reproduces
the refusals - including the silent drops, since a mock that applied them
would let a client that sends them look correct everywhere but a real
server.
This commit is contained in:
2026-08-30 21:35:01 -07:00
parent 6ec2304fc2
commit dd8998f178
11 changed files with 923 additions and 54 deletions
+89
View File
@@ -0,0 +1,89 @@
import { choiceDialog, confirmDialog } from "@/ui/dialog";
import { isOccurrence, isRecurring, isThisAndFutureRefusal, type EventScope } from "@/store/calendar";
import type { CalendarEvent } from "@/jmap/types";
/**
* Ask which of a series a change is meant for, when there is a choice.
*
* There is only a choice when the object in hand is an occurrence of a real
* series: a one-off has a synthetic id too, but its only occurrence *is* the
* event, so asking would be a question with one true answer. `null` means the
* dialog was dismissed, which is not the same as "the whole series" — every
* caller has to treat it as a cancel.
*
* Until 0.16.20 there was nothing to ask: the server refused a write aimed at
* an occurrence, so "the whole series" was the only thing that could happen.
*/
export async function askScope(
event: CalendarEvent,
opts: { title: string; occurrenceLabel: string; seriesLabel: string; danger?: boolean; occurrenceHint?: string; seriesHint?: string },
): Promise<EventScope | null> {
if (!isRecurring(event) || !isOccurrence(event)) return "series";
const answer = await choiceDialog({
title: opts.title,
choices: [
{ value: "occurrence", label: opts.occurrenceLabel, hint: opts.occurrenceHint, danger: opts.danger },
{ value: "series", label: opts.seriesLabel, hint: opts.seriesHint, danger: opts.danger },
],
});
return answer === "occurrence" || answer === "series" ? answer : null;
}
/** The scope question for deleting. */
export const askDeleteScope = (event: CalendarEvent): Promise<EventScope | null> =>
askScope(event, {
title: "Delete this event?",
occurrenceLabel: "This occurrence",
occurrenceHint: "Removes this date and leaves the rest of the series.",
seriesLabel: "All occurrences",
seriesHint: "Deletes the whole series. This cannot be undone.",
danger: true,
});
/** The scope question for editing. */
export const askEditScope = (event: CalendarEvent): Promise<EventScope | null> =>
askScope(event, {
title: "Change this event?",
occurrenceLabel: "This occurrence",
occurrenceHint: "Applies to this date only.",
seriesLabel: "All occurrences",
seriesHint: "Applies to every date in the series.",
});
/**
* What to say when the server kept some of a per-occurrence change for the
* series. `dropped` comes back from `updateEvent`; an empty list says nothing.
*/
export function droppedMessage(dropped: string[]): string | null {
if (!dropped.length) return null;
const names = dropped.map((d) => d.replace(/^@/, "")).join(", ");
return `Saved for this date. ${names} ${dropped.length === 1 ? "applies" : "apply"} to the whole series and was left unchanged.`;
}
/**
* Run a scoped change, and offer the series if the server will not do one date.
*
* Stalwart refuses an occurrence that belongs to a this-and-future override —
* *"Occurrences of a this-and-future change cannot be modified individually."*
* Nothing ihasmail writes creates one, but an event synced from another client
* can carry one, so the refusal is reachable and a bare error toast would leave
* the reader with no way forward.
*
* The series is offered rather than silently substituted: they asked for one
* date, and doing the larger thing without saying so is the failure this whole
* area exists to avoid.
*/
export async function runScoped<T>(scope: EventScope, run: (scope: EventScope) => Promise<T>): Promise<T | null> {
try {
return await run(scope);
} catch (err) {
if (scope !== "occurrence" || !isThisAndFutureRefusal(err)) throw err;
const ok = await confirmDialog({
title: "This date cannot be changed on its own",
message: "It belongs to a change that was applied to this and all later occurrences, which the server will only edit as a whole. Apply to the entire series instead?",
confirmLabel: "Apply to series",
});
return ok ? await run("series") : null;
}
}