- Ya
- 30 Agosti 2026, 18:14 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 9c8c502
The checkbox beside each calendar was bound to `calendar.isVisible` and its onChange was `fetchEvents`. `isVisible` is sent by EmailService and written back by nothing on the platform — all 69 active rows in `user_calendars` carry `is_visible = true` — and refetching events changes no state the box reads. So React re-rendered the box with the `checked` it already had and the click vanished. Always checked, never uncheckable, in every org: exactly what was reported. The page already had the state this control wanted. `selectedCalendarIds` filters `filteredEvents`, and the identical checkbox list inside CalendarSearchBar toggles it correctly. The sidebar was simply never wired to it, so two controls over one concept disagreed and the more obvious one was the dead one. Unchecking the last calendar had a second bug waiting behind the first. The filter was guarded with `selectedCalendarIds.length > 0`, so an empty selection fell out of the filter altogether and every event came back — the member clears the list and the grid fills up. Empty could not mean "none of them" while it also meant "not loaded yet", so those two states are now separate values, `[]` and `null`, in **************** Which meant the initialiser had to stop using "the selection is empty" to decide it had never run, or an all-unchecked calendar would re-check itself on the next render of the list. It now tracks the calendar ids it has seen: a calendar the page has never shown starts visible, and one the member unchecked stays that way. That also fixes a newly created calendar's events being filtered out of the grid it was created from. The selection stays view state rather than a saved preference, which is what the search bar's copy of it already was. Persisting it needs a column something actually writes.