- Shipped
- September 9, 2026 at 4:30 AM UTC
- Author
- Kamo
- Commit
- cff3913
AchievementController checks VIEW_ACHIEVEMENTS on all four of its endpoints, and that read like the rule being enforced. It was not: it is the rule enforced on the one seam that happens to have a session. Four others award with no caller at all — * **************** hung off POST /api/security/session/extend, the keepalive EVERY signed-in browser calls whatever rights it holds; * MemberCreationService, which awards the baseline to every member created; * **************** nightly, over whoever owns a tracking code; * AchievementInternalController, called by MediaService on the cluster secret. So a member whose role denies the right earned nothing they could see and then appeared on their colleagues' leaderboard anyway. Reported against kamocrm, where "Members" has rights 304-310 denied; the affected member's only row was LOITERING, which is the keepalive's signature and nothing else's. record() is the single write behind every seam, so the check goes there and a caller added later gets it for free. Putting it on the fifth controller would have fixed the one report and left the other three to produce the next one. Read from member_rights_applied, not from the session: three of those seams have no session, and that table is what the session bake itself projects from, so the awarding rule and what the member can actually open cannot disagree. No god branch — hasRight lets a platform administrator read past a missing right, which is right for reading and is not a reason to write a record into a tenant's organization for a member that tenant excluded.