- Shipped
- August 14, 2026 at 7:07 PM UTC
- Author
- Kamo
- Commit
- dcdca6d
The centre could answer one question: the most recent hundred, unread or not, with no way to ask for what had already been read. So anything a member had seen was, in practice, gone — which is a poor property for the record of what the application has told someone. GET /api/notifications/browse pages, reports the total, counts each kind for a filter rail, and takes a status of all, unread or read. The existing list stays as it was: it fills the live deck, which wants the newest few and nothing else. Built from predicates rather than a query per combination of filters, and deliberately not from (:kind IS NULL OR ...) — an untyped null parameter is what made every calendar lookup 500, and an omitted predicate cannot do that.