Invitations that carry a role
An invitation can now name the role the person lands on, and it arrives by email instead of waiting to be found. Owners can read what the built-in roles grant, and the last console controls that ignored permissions now respect them.
Added
3- Access controlAn invitation can name the role the person lands on. Inviting somebody previously offered Member or Admin, and Member grants nothing, so the normal case was to invite a content editor, watch them land on the no-access page, and then go and find the change-role dialog. The invite dialog now lists the organization's own roles.
- UsersInvitations are emailed. An invitation was only discoverable by signing in and finding the invitations screen, so the inviter usually ended up messaging the person separately to say it was there. The mail comes from an address we control and can sign for, with the inviter in Reply-To so there is still a human to answer.
- Access controlOwners and admins can open the built-in roles and read what they grant. The user role is the one that matters: it is the default for an invitation and grants nothing, so a new member lands on the no-access page everywhere and it looks like the invite failed. Each role now says what it is, read-only.
Fixed
7- Access controlCreating an auth client now shows its client ID, client secret and organization ID in a dialog you can copy from. The secret only ever exists in that one response - every read of a client masks it to its first and last five characters - so the console was quietly dropping the single copy of it, and a client created in the console could not be configured without deleting it and starting again. The client screen also has a Regenerate button now, for a secret that was lost or leaked: it mints a new one, shows it the same way once, and retires the old one immediately.
- ConsoleEvery console write is gated behind the permission it needs. A role with read access could still find create, update and delete controls enabled. The API refused those requests, so nothing was exploitable, but a console full of buttons that answer 401 reads as a broken product rather than a permission you lack. The workflow editor was the worst case: it auto-saved on any canvas interaction, so a viewer nudging a node wrote to the draft.
- Access controlGranting, revoking and reconciling a workspace's credits are gated on the permission the server actually enforces, rather than on the screen around them, so the buttons no longer offer something the API refuses.
- ConsoleThe roles editor lists only the permissions a role does not already hold. It previously rendered every grantable resource, so on a role holding a lot the two tables were near-identical with every box ticked in both, which reads as a broken screen rather than "there is nothing left to add".
- Access controlThe owner role states the rule it follows instead of showing a permission matrix. Owner is a bypass, not a set of permissions, so listing its rows implied it was the same thing as admin and that unticking one would limit it. Neither is true.
- ConsoleA control you cannot use no longer shrinks what it wraps. Gated cards and tables collapsed to their content width, so a screen that was merely read-only looked broken, and only for the people who could not use it.
- EmailPlatform mail is sent from the mail subdomain, which is where the relay signs, so DKIM aligns with the From domain instead of failing alignment. It also keeps transactional and marketing sending reputation apart.