2026.10.10 — 2026-10-06

Breaking

• Apply access changes to the next request and resolve team access (3a98ab9d)

  A signed-in user's access is no longer frozen at sign-in. The permission check reads the user's current role grants and team roles, so granting a role, joining a team or having an account disabled applies on the very next request of a session that is already open, on every Studio replica. Studio no longer ends a role's members' sessions when the role's permissions are edited; it still ends them when a grant is removed, an account is disabled or a role starts to require a second factor.

  The check now also decides for a named queue or address: a team member holds their team role on what the team's patterns own, and the members of a team a pattern is shared with hold the share's role on what it covers. A permission acts at one scope: a global permission takes effect only through a global grant, a cluster permission through a global, environment or cluster grant, and a resource permission through those or a team. A permission that no enabled feature or active plugin declares grants nothing, wildcards included.

  External users' directory groups are now kept from their last sign-in, so a team can hold a group as a member, and a user with no mapped role and no default role may sign in when they are a team member, directly or through a group.

  A role can no longer be saved without the permissions the ones it holds require (queue:purge needs queue:read, for example), and a role marked as a team role may hold only permissions that act on a queue or address, plus team:admin. The role API gains teamAssignable.

• Declare the scope each permission acts at (001bc38c)

  Every permission now says where it takes effect: global (checked without a cluster), cluster (checked against a cluster) or resource (checked against a queue or address, with the queue and address kinds it acts on). It can also list the permissions a role must hold with it (requires). This replaces globalOnly, which is gone from the catalogue, the permission API and the plugin manifest.

  New permissions: queue:read, address:read, address:create, rr:write, connection:read and team:admin. The permission catalogue endpoint returns scope, resourceKinds and requires instead of globalOnly. The health check also reports a required permission that is not in the catalogue, a requirement cycle and a resource permission without a kind.

Added

• Manage teams, their patterns, members and shares (78b9ee27)

  Administrators can create, rename and delete teams, give a team queue and address name patterns per cluster, add users or directory groups as members with a team role, and share part of a team's patterns with another team. A pattern is refused when some name on that cluster and kind could match both it and another team's pattern, naming that team and pattern. A share must lie within one of its owner's patterns. Endpoints under /api/v1/teams, plus a pattern preview that counts what a pattern covers on a cluster, shows up to 20 names and lists the clashes, and /api/v1/clusters/{id}/unowned, the names that no team owns.

  Everything needs user:admin, except that a holder of team:admin in a team can add, change and remove that team's members, only with roles no wider than their own in that team. Every change is audited and applies on the next request.

  Role editors that create roles with the demo and QA seed scripts need queue:read now that message:read requires it; the scripts grant it.

• Apply access changes to the next request and resolve team access (3a98ab9d)

  A signed-in user's access is no longer frozen at sign-in. The permission check reads the user's current role grants and team roles, so granting a role, joining a team or having an account disabled applies on the very next request of a session that is already open, on every Studio replica. Studio no longer ends a role's members' sessions when the role's permissions are edited; it still ends them when a grant is removed, an account is disabled or a role starts to require a second factor.

  The check now also decides for a named queue or address: a team member holds their team role on what the team's patterns own, and the members of a team a pattern is shared with hold the share's role on what it covers. A permission acts at one scope: a global permission takes effect only through a global grant, a cluster permission through a global, environment or cluster grant, and a resource permission through those or a team. A permission that no enabled feature or active plugin declares grants nothing, wildcards included.

  External users' directory groups are now kept from their last sign-in, so a team can hold a group as a member, and a user with no mapped role and no default role may sign in when they are a team member, directly or through a group.

  A role can no longer be saved without the permissions the ones it holds require (queue:purge needs queue:read, for example), and a role marked as a team role may hold only permissions that act on a queue or address, plus team:admin. The role API gains teamAssignable.

• Rebuild the built-in roles for resource-scoped permissions (6c68e760)

  The permissions of the built-in roles are re-seeded when Studio upgrades, and every holder of Operator or Viewer gets the new sets. Nothing a role held before is removed.

  Operator now holds every cluster and resource permission that operates brokers, so it adds creating, updating, deleting and pausing queues, creating addresses, diverts and capture, closing connections and request-reply writes. Viewer holds every read permission, so it adds queue, address, connection, governance and data reads. Operator still lacks broker configuration, Studio settings and credentials, users, roles, teams, tokens, plugins and data, and the sensitive-value permission message:clear. Review who holds Operator before upgrading.

  Three team roles are added: Team Viewer (TEAM_VIEWER), Team Operator (TEAM_OPERATOR) and Team Admin (TEAM_ADMIN), usable as the role of a team member.

  A test fails whenever a new core permission is neither in a built-in role nor listed as deliberately excluded.

• Add the team tables and clean up grants of a deleted cluster (61e2d9ba)

  Adds the schema teams are built on: a team, the queue and address name patterns it owns per cluster, its members (a user, or a group of an identity provider, holding one team role) and the shares of one team's patterns with another. A role can be marked team-assignable.

  Deleting a cluster now also removes the role assignments and group mappings scoped to it, which were left behind before, and the team patterns and shares on it.

• Declare the scope each permission acts at (001bc38c)

  Every permission now says where it takes effect: global (checked without a cluster), cluster (checked against a cluster) or resource (checked against a queue or address, with the queue and address kinds it acts on). It can also list the permissions a role must hold with it (requires). This replaces globalOnly, which is gone from the catalogue, the permission API and the plugin manifest.

  New permissions: queue:read, address:read, address:create, rr:write, connection:read and team:admin. The permission catalogue endpoint returns scope, resourceKinds and requires instead of globalOnly. The health check also reports a required permission that is not in the catalogue, a requirement cycle and a resource permission without a kind.

• Add a wildcard pattern matcher with exact overlap and containment (28f19702)

  Queue and address name patterns in the broker's own syntax (words split by '.', '*' one word, '#' zero or more) can be parsed, matched against a name, tested for overlap and tested for containment. Overlap is exact (a dynamic program over both patterns); containment walks both patterns' automata and compares them with brute-force enumeration in the tests.

Fixed

• Never keep access read from before a change was announced (d4205b40)

  A permission check that loaded a user's access, or the team ownership index, while a change to it was being committed could store what it read and keep serving it after the change was announced, until the next unrelated change. A read now counts the announcements and is only kept when none arrived while it ran; it is still used for the request that made it. The ownership index also expires after a minute, as the per-user cache already did.

Security

• Enforce team roles' second factor and bound what a team admin can do (2eea6692)

  A role that requires a second factor now applies to the users who hold it as a team role, directly or through a directory group: signing in needs a factor, adding a member to such a role ends the member's open sessions, and making a team role require one ends its members' sessions. Before, only roles granted to a user outside teams were considered.

  A team admin can manage only a team's user members. Adding, changing or removing a directory group, which can admit users to Studio, needs user:admin. A team admin also cannot change or remove a member whose role holds a permission they do not hold in that team, so they cannot demote or remove someone above them.

  Two teams adding overlapping patterns on a cluster at the same time can no longer both succeed: pattern changes of one cluster are serialised by a database lock until the transaction ends.