- Shipped
- August 15, 2026 at 5:22 AM UTC
- Author
- Kamo
- Commit
- 89ccc1b
MailboxController enforced no right at all. MANAGE_EMAIL_ACCOUNTS existed only as a checkRight in the browser and VIEW_EMAIL_ACCOUNTS was referenced nowhere, so every mailbox in an organization could be created, suspended, deleted or reassigned by any authenticated caller who knew the URL. Changing anything now takes MANAGE_EMAIL_ACCOUNTS; reading administrative detail — who is assigned to a mailbox, what the provisioning provider supports — takes VIEW_EMAIL_ACCOUNTS. getMailboxMembers, unassignMailbox and setPrimaryMailbox took no HttpServletRequest at all, so they had neither a rights check nor an organization check: any caller could reassign any mailbox by id. They take the request now. The list endpoint is deliberately NOT gated. GET /api/email/mailboxes is the first source in /api/email/directory, which backs the recipient autocomplete behind useRecipientSearch, and that route returns an empty list rather than an error when a source refuses. VIEW_EMAIL_ACCOUNTS is held by 15 of 42 roles and ACCESS_MAIL by 28, so gating the list would have silently emptied colleagues out of the address book of every member who can read mail but not administer it, with nothing to explain it. Whose mailboxes a member may open is already decided by ACCESS_ALL_*_MAILBOXES through AccessibleMailboxService. One endpoint serving both the admin screen and the address book is the real defect. Splitting it would let the admin view take the right it should — an API change rather than an authorization one, so not made here. The class javadoc records this so the next person does not "fix" the missing gate and break autocomplete.