- Ya
- 14 Agosti 2026, 06:01 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 991e482
Three faults, one symptom. Members reported that calendar notifications did not work, and all three reasons were on this side. Reminders were never written. The API accepted a reminders list on every event, MemberCalendarService dropped it, and only meeting invitations ever produced a reminder row — so every event created in the calendar UI notified nobody, and nothing in the interface said so. Create and update now persist them, defaulting a new event to the member's own preference. "Nothing" and "none" stay distinct: an empty list is the member having deleted every reminder, not an omission. A reminder reached one person. The scheduler resolved recipients as the account that created the event, so an event on the organisation-wide calendar reminded its author and nobody else, and a guest invited to a meeting was told nothing. The organisation calendar belongs to no user, so that lookup could also return nothing and the reminder simply evaporated. ReminderRecipientResolver answers properly: the whole organisation for a shared event, the owner for a personal one, plus any guest who is a member of the same organisation. Moving an event stranded its reminders. They kept pointing at the old time and stayed flagged as sent, so the member was reminded about the time it was no longer at and then not at all. Both edit paths now re-derive and re-arm them. Reminders are raised through MemberNotificationService rather than published straight to the socket, so a member who was on another tab, in another application or signed out still finds the card waiting — and so mutes, quiet hours and do-not-disturb apply to reminders like anything else. Also closes a hole in the socket: **************** was unguarded, so any authenticated member could subscribe to anyone's reminders and read who was meeting whom. It and the new notification topic are now checked against the member id the handshake already stamps on the session.