Bring the stranded calendar work into main #33

New Issue

Closed

opened 2026-08-25 16:06:21 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-25 16:06:21 +00:00

Owner

#26, #30 and half of #25 are not actually in main. This brings them in. No new work — it is the tail of calendar-recurring-warning that main never saw.

What happened

#31 was stacked on calendar-recurring-warning rather than on main. #28 merged that branch into main at 07:53; #31 merged into the same branch at 08:42, and two corrections to #25 were pushed to it before that. Main's snapshot was taken before any of it, and the branch was never merged again — so #28 landed with only its first commit.

What main is missing:

8bed916 Merge pull request #31 from LINUXexpert-org/calendar-stalwart-vocabulary
3525d5c Record that RSVP and the edit path hold up too
4fe9835 Record that the invitation reached a real guest and came back
217e765 Say it in the words Stalwart 0.16 answers to
f6004b0 Ask the recurrenceId, which is the part that survives expansion
62e3b7a Ask only the recurrence rules, the live server settles it

The consequences on a real 0.16 server, all of them the bugs the issues describe:

#25 is still broken. Main has isRecurring testing baseEventId !== ev.id, which a live 0.16.19 disproved: a one-off comes back as id eaaaaai over base i, so every event still reads as a series.
#26 is still broken. EventEditor still writes sendTo/email, which Stalwart silently discards. Guests still vanish, no invitation is sent.
#30 is still broken. Still recurrenceRules, still rejected.

This PR

origin/main merged with origin/calendar-recurring-warning. Clean merge — the branch never touched the files #27, #29 and #32 changed, so their work is untouched.

Checked explicitly after merging: isRecurring is the recurrenceId version; makeParticipant/calendarAddress present; reorderRules and the drag handle still there; the named-header column still there.

npm run typecheck, npm test — 201 web + 88 server, all passing (26 test files, up from 23: the participant and drag-reorder suites now coexist).

Note

I closed #26 and #30 on the strength of #31 being merged, without checking that main had it. They describe live bugs until this lands. Reopen them if this is not going in shortly.

Merged 2026-08-25 as coffey-labs/ihasmail@b0be465e50

_{Rebuilt from: git history, session transcript.}

**#26, #30 and half of #25 are not actually in main.** This brings them in. No new work — it is the tail of `calendar-recurring-warning` that main never saw. ## What happened #31 was stacked on `calendar-recurring-warning` rather than on main. #28 merged that branch into main at 07:53; #31 merged into the same branch at 08:42, and two corrections to #25 were pushed to it before that. Main's snapshot was taken before any of it, and the branch was never merged again — so #28 landed with only its first commit. What main is missing: ``` 8bed916 Merge pull request #31 from LINUXexpert-org/calendar-stalwart-vocabulary 3525d5c Record that RSVP and the edit path hold up too 4fe9835 Record that the invitation reached a real guest and came back 217e765 Say it in the words Stalwart 0.16 answers to f6004b0 Ask the recurrenceId, which is the part that survives expansion 62e3b7a Ask only the recurrence rules, the live server settles it ``` The consequences on a real 0.16 server, all of them the bugs the issues describe: - **#25 is still broken.** Main has `isRecurring` testing `baseEventId !== ev.id`, which a live 0.16.19 disproved: a one-off comes back as id `eaaaaai` over base `i`, so every event still reads as a series. - **#26 is still broken.** `EventEditor` still writes `sendTo`/`email`, which Stalwart silently discards. Guests still vanish, no invitation is sent. - **#30 is still broken.** Still `recurrenceRules`, still rejected. ## This PR `origin/main` merged with `origin/calendar-recurring-warning`. Clean merge — the branch never touched the files #27, #29 and #32 changed, so their work is untouched. Checked explicitly after merging: `isRecurring` is the `recurrenceId` version; `makeParticipant`/`calendarAddress` present; `reorderRules` and the drag handle still there; the `named-header` column still there. `npm run typecheck`, `npm test` — 201 web + 88 server, all passing (26 test files, up from 23: the participant and drag-reorder suites now coexist). ## Note I closed #26 and #30 on the strength of #31 being merged, without checking that main had it. They describe live bugs until this lands. Reopen them if this is not going in shortly. **Merged** 2026-08-25 as coffey-labs/ihasmail@b0be465e5076 <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#33