- Shipped
- September 23, 2026 at 3:50 AM UTC
- Author
- Kamo
- Commit
- bb3ff15
**************** on /api/email/shared-mailboxes needed only a session — any authenticated member could create a shared mailbox, delete one, or grant themselves (or anyone) access to one they were never given, and SharedMailboxMailController then reads and sends through that access row. Org scoping already existed at the service layer; nothing above it ever asked whether the caller was allowed to manage shared mailboxes at all. The five now require MANAGE_EMAIL_ACCOUNTS, the same right MailboxController's equivalent personal-mailbox admin actions already enforce (2026-08-14) — same settings screen, same class of action. The list endpoint is not refused for a caller without the right: it changes shape instead, answering only the mailboxes that member has been granted access to (the set /my-access already answers), never the whole org's list. **************** fails without the change — a spoofed grant, or a delete, would otherwise succeed (200) instead of being refused (403), and the unprivileged list would return every mailbox in the org instead of only the caller's own.