Bell: lock-expiry notifications + retention horizon + feed cache (#402) #403
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "lock-notify"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implements #402 as ratified (mockup approved).
Lock-expiry notification — derived, not stored:
filelock.LapsedForsurfaces manual locks the admin cap has expired (they stay recorded since #394), and the feed turns them intolock-expireditems timestamped at the lapse moment. Bell renders them with a new open-shackle padlock in the lock tint; meta reads "Your lock expired (enforced by admin setting)" ×4 locales. Cap off or unlock → the item vanishes with the state, as a view should.Retention —
notifyRetentionDays(0/absent = 30, max 365, no "forever"), new row in Basic settings whose first card is now titled Name & Notifications (all four locales). It drives three prunes, all lazy on existing writes, no sweeper: feed horizon (all kinds), lapsed-lock records dropped once lapsed longer than the horizon (locks.jsonbounded), andnotify-seen.jsonwatermarks older than the horizon dropped on save (lossless — such a watermark equals none; the file is bounded by users active within the window). Basic settings page description updated accordingly.Scale guard — per-user in-memory feed cache (45 s TTL): derivation (1+P backend LISTs) runs at most once per user per interval however many tabs and devices poll. Watermark filters run per request on the cached items, so read-all/clear stay instant with no invalidation needed.
Tests: lapse detection (per-owner, lapse moment, no-cap = none), retention prune keeps live locks and drops long-lapsed ones (+ mutation check on the lapse comparison), watermark prune keeps fresh and drops stale, NotifyRetention default/explicit/validation bounds.
Closes #402.