- Ya
- 22 Agosti 2026, 08:51 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 626d405
GET /api/notes/master answers both and provisions whichever is missing. PUT /api/notes/master/org writes "Our Master Note", addressed by organisation rather than by note id, so there is nothing to guess and no other organisation's note to reach. Editing it takes MANAGE_ORG_MASTER_NOTE or ownership of the organisation — the owner floor is the anti-lockout guarantee, since the right is deliberately not seeded onto existing roles. GET /master deliberately takes NO notes right. VIEW_NOTES gates the Notes *app*; these are fixtures of the home launchpad, and "every member always has one" has to mean every member. The ordinary listings keep their VIEW_NOTES gate and now also return the organisation's note, so it is readable and searchable on the wall. The rules are enforced here rather than in the client: a master note cannot be deleted (409 — a fact about the note, not about who is asking), cannot be unpinned, and cannot be renamed. Title and pin are ignored rather than rejected, because the editor sends every field on every save and refusing the request would fail an edit to the BODY over a title the member never touched. Content keys follow scope: keyForOrg(orgId) for the organisation's note, so every member of the organisation can read it. Deriving it from whoever wrote it would make a shared note readable by one person. Provisioning is its own bean and its own transaction, and does every read before its first write: since the move to Yugabyte a SELECT after a write in one transaction can come back 40001 and abort it. A private method on NotesService would have been inert as @Transactional and run in the caller's transaction.