The owner may set the owner role's colour (GRYT-906, GRYT-907)

[sivert-io]

Two changes to the role editor's server half. The client halves are client#386 (opened alongside this).

The owner role's colour saves

server:roles:definitions:save refused every edit to the owner role:

if (roleId === OWNER_ROLE_ID) {
  socket.emit("server:error", { error: "forbidden", message: "The owner role cannot be edited." });
  return;
}

The reason holds for name, rank and permissions — services/permissions falls back to the owner role when a lookup fails, and it is the only thing between a mistake in that editor and a server nobody can administer. A colour is not part of that: it grants nothing, moves nobody, and locks nobody out. Refusing it was the blanket rule catching something it was not written for.

The exception is deliberately narrow:

• Every other field must be absent, not merely ignored. A payload carrying a rank or a permission beside the colour is refused whole rather than half-applied.
• Everything written back comes from the row as it stands, so no path through here changes anything but the colour.
• It sits before the two rank checks, because it has to — the owner role's rank is the owner's own, so existing.rank >= auth.rank refuses the owner editing their own role.

What to look at

• The extra gate, and whether you agree with it. manage_roles alone would let a delegated admin recolour the owner role so the owner reads as an ordinary member. Small, but social engineering for no benefit, so this also requires auth.rank >= existing.rank — in practice, the owner. If you would rather any manage_roles holder could do it, delete that block; the test names the case.
• The !saved branch. updateRoleDefinition returns null if the row went between the read and the write. Emitting server:roles:definition:updated there would have clients drawing a colour the server does not hold.

roleEditorState sends identityTiers

The editor offers an "As a guest" default role with a footnote underneath explaining the setting may never be used, because it had no way to tell. getAcceptedIdentityTiers() already exists and is already on /api/server-info; this puts it on the payload the tab already reads, so the client can disable the control and say why. Read-only, admin-only — it goes to a handler already gated on manage_roles.

Verification

yarn test (713 tests), yarn build and npx eslint . all pass; the two eslint warnings are pre-existing and in files this does not touch.

ownerRoleColour.test.ts is new — 19 cases, and most of them are about the hole being no wider than intended. Mutation-tested, all four caught:

mutation
colour-only guard stops checking the other fields	caught
colour path writes the payload's permissions	caught
rank gate on the owner colour removed	caught
colour written without normalising	caught

🤖 Generated with Claude Code