Aliases and shared-mailbox access name their members as text

FixEmailService
Shipped
September 18, 2026 at 6:07 AM UTC
Author
Kamo
Commit
9e4dd6f

GET and POST /api/email/aliases (and /aliases/member/{id}) and GET and POST **************** answered with the entities themselves, whose Long memberId and grantedByMemberId went out as JSON numbers. Member ids are INT8s past 2^53, so the browser rounded them: Settings → Email → Aliases matched nobody and printed the rounded number under "Assigned to"; Shared Mailboxes named nobody on its access chips and never took a granted member out of the "grant access to" list; and revoking sent the rounded id back, which matched no row and removed nothing. The controllers now answer with AliasView and AccessView: the entity's own fields, names and values unchanged, with the member ids as text. Every consumer already reads them as strings: kamo-internal's EmailAlias and SharedMailboxAccess types say string, and the directory route, the composer, kamo-js email-core and the mobile app read only an alias's address, name and id. AliasResponseMemberIsTextTest and **************** fail without the change on every endpoint, and prove each view writes exactly what the entity did apart from the member ids. **************** now expects the id as text.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing