After editing a calendar event, community selection is lost and must be re-selected

laoc commented

2026-07-08 10:43:14 +00:00

Owner

Report (Comenius test report)

etwas irritierend: muss ich nach Bearbeitung nochmal neu die Communities auswählen?

When editing an existing calendar event, the communities it was shared with are not pre-selected in the edit form — the user has to pick them again, and it is unclear whether not re-picking them un-shares the event.

Screenshot from the report:

Expected

The edit form pre-selects the communities the event is already shared with, and saving without changes keeps the sharing state untouched.

## Report (Comenius test report) > etwas irritierend: muss ich nach Bearbeitung nochmal neu die Communities auswählen? When editing an existing calendar event, the communities it was shared with are not pre-selected in the edit form — the user has to pick them again, and it is unclear whether not re-picking them un-shares the event. Screenshot from the report: ![community selection after edit](https://pad.gwdg.de/uploads/a83cfc72-797d-4fdc-b36b-3813de552de8.png) ## Expected The edit form pre-selects the communities the event is already shared with, and saving without changes keeps the sharing state untouched.

laoc added the

bug

label

2026-07-08 10:43:14 +00:00

laoc commented

2026-07-08 11:20:49 +00:00

Author

Owner

Fixed on branch fix/issue-8-edit-communities. This was worse than a UI irritation:

updateEvent extracted only the FIRST h-tag from the existing event, so editing an event shared with several communities silently un-shared it from all but one.
The edit modal showed the community selector unchecked and ignored it on save.

Now: the edit modal pre-selects the communities the event is already shared with; saving applies the (possibly edited) selection, so unchanged selections keep the sharing exactly as it was, and un-checking really un-shares. h-tags pointing at communities the editor has not joined (not rendered by the selector) are preserved through save and the Select-all/Deselect-all bulk actions.

Covered by new unit tests for the h-tag handling in updateEvent. The modal flow itself was verified by code review + type check; a full e2e pass over calendar editing would be a good follow-up before deploy.

Fixed on branch `fix/issue-8-edit-communities`. This was worse than a UI irritation: - `updateEvent` extracted only the FIRST h-tag from the existing event, so editing an event shared with several communities silently un-shared it from all but one. - The edit modal showed the community selector unchecked and ignored it on save. **Now:** the edit modal pre-selects the communities the event is already shared with; saving applies the (possibly edited) selection, so unchanged selections keep the sharing exactly as it was, and un-checking really un-shares. h-tags pointing at communities the editor has not joined (not rendered by the selector) are preserved through save and the Select-all/Deselect-all bulk actions. Covered by new unit tests for the h-tag handling in `updateEvent`. The modal flow itself was verified by code review + type check; a full e2e pass over calendar editing would be a good follow-up before deploy.

laoc referenced this issue

2026-07-09 08:56:28 +00:00

Community shares are published only to the sharer outbox — invisible on community relays #21

laoc referenced this issue from a commit

2026-07-09 09:08:44 +00:00

fix(community): make shares reach community relays and community surfaces

laoc commented

2026-07-09 09:10:20 +00:00

Author

Owner

The remaining part of the test report (share invisible in feed/upcoming, unchecked checkbox) was investigated and fixed under #21 — see the causal chain there. The edit-modal pre-selection from this issue is unchanged and awaiting re-test.