- Shipped
- August 15, 2026 at 1:49 AM UTC
- Author
- Kamo
- Commit
- cb1efaf
NotesController checked no right on any of its ten endpoints. VIEW_NOTES was enforced in exactly one place — navRegistry.ts, hiding the Notes app in the browser — so the 22 members whose roles withhold it were refused the page and served by the API. CREATE_NOTES, EDIT_NOTES and DELETE_NOTES gated nothing at all. Reads and the tag, category and version-history lookups now take VIEW_NOTES, create takes CREATE_NOTES, update and version restore take EDIT_NOTES, delete takes DELETE_NOTES. Restore is an edit rather than a read: reading the history leaves the note alone, putting a version back overwrites its current content. SessionHelper.hasRight had to be fixed in the same change or all ten would have been decorative. It returned true for a session with an empty rights list and again for one with no rights field, commented "rights system not yet enforced" — and every gate in this service is built on it, including the knowledge-base rights that are documented elsewhere as the fully enforced group. A caller arriving without rights attached was granted everything, MANAGE_KB_RESOURCES included. Nothing ever marks a session as legacy, so that exemption could never expire; it had stopped being a migration aid and become a bypass. Safe to close, and checked rather than assumed: rights reach the session from member_rights_applied, all 69 members have rows there, and no service calls these endpoints without a user session. No seeding, for once, and that is measured too. No member holds VIEW_NOTES without all three write rights, so nobody loses a capability. Three notes exist, owned by two members, and both hold all four rights — no note becomes unreachable by its owner. The members who lose API access could only have reached it by bypassing a nav entry the browser already refused them, which is the bypass this closes.