People settings
People settings cover accounts and access: who has one, what a service account is, how teams group people, and what a role grants. This page documents each section field by field.
Open Settings → Users to see every account on the server: its auth source, activity, last sign-in, and its server-wide instance access.
Instance access is a two-rung switch, not a role: Administrator or Member. Only another administrator can flip it, and an administrator bypasses every permission check. This is separate from a granted role — see Roles below — and separate from the Baseline role, which every account holds without being granted anything.
Click Deactivate to revoke a person's sessions and block every sign-in path for their account. Click Activate to reverse it.
TODO(verify): this page has no control to invite or manually create a person's account.
POST /usersexists on the server, gated by theuser.createpermission atom, but nothing in Settings → Users calls it. The paths that actually create an account are self-service sign-in (local registration, or SSO within the configured signup allowlist) and the Import from AD link to Directory settings, which bulk-imports accounts from the directory. Confirm whether an invite flow is planned or was removed before publishing this as settled behaviour.
The page lists possible duplicates below the table — accounts that share an email's local part or a name. Click Merge… to fold one into another. Select the account to keep. Everything that references the others — items, comments, worklogs, watchers, memberships, history — repoints to it. The server signs the folded-in account out and deactivates it, keeping it for audit rather than removing it.
Click Delete on a row to remove an account permanently. The dialog shows what the account owns — reported items, comments, wiki pages, and more — before anything happens.
If the account owns anything, you must select who inherits it before you can confirm. That successor must already hold at least as much access as the account you are deleting — the server never transfers access itself, only content. Worklogs are destroyed, not moved: crediting someone else with hours they did not work would skew every timesheet and time report. Export a person's worklogs first if you need to keep them. A team the account owns loses its owner instead — the server does not reassign it automatically.
Open Settings → Service accounts. A service account authenticates only with an API key. It has no password, and it cannot sign in the way a person does. Its authority comes from the roles you grant it, the same way a person's does.
Click New service account to create one, then click Keys to mint an API key for it. A key can carry the account's full authority. To narrow it instead, select a scope — global, or one project — and list the permission atoms the key should carry.
A key can never exceed its account. The server intersects the key's listed atoms with what the account actually holds. Naming an atom the account lacks is harmless — it is never an escalation.
The server shows a minted key's value once, at creation. You need the
global.manage permission atom to manage service accounts and their keys.
Open Settings → Teams. A team groups people, then attaches to a project with a role — that attachment is what grants the team's members access to the project.
Click New team to create one. You need the team.create permission
atom to create a team. Administering an existing team needs only that
team's own management access — granted to its owner, one of its managers,
or anyone holding the global team permission atoms.
Who runs this team shows the owner and lets you transfer ownership or add managers. A manager can edit the team's roster and rename it. A manager cannot appoint further managers, transfer ownership, delete the team, or attach it to a project. Delegating a team this way never widens what the team itself can do. A manager need not be a member of the team they run.
Directory groups links the team to one or more mirrored AD groups. Every person in a linked group, including nested groups, counts as a team member. A member added this way carries a badge naming the group. You cannot remove that member one at a time from this panel — remove the whole group instead, or let the next directory sync catch a departure. Members you add by hand stay fully editable, regardless of any linked group.
Click Grant role to give the team a role. You need the role.update
permission atom, held globally, to grant or revoke a role here. This is
distinct from running the team day to day.
Leave Projects and Wiki spaces both empty to grant the role everywhere on the server. Name one or more projects, or spaces, to grant it only there.
Open Settings → Roles. A role is a named set of permission atoms —
the same atoms every settings section refers to, such as item.read or
field.manage. Granting a role to a person, a team, or a directory group
hands them every atom in the set, at whatever scope the grant carries.
Click a role's row to expand its permission matrix. A checked atom is part
of the role. Some atoms carry a relation qualifier that narrows which
rows the atom applies to. An item.read atom, for example, can be scoped
to items you are assigned, items you reported, or any item.
Four roles are built in: Baseline, Admin, Member, and Viewer. Their permission sets are fixed, with one exception. Every active account holds Baseline everywhere, and nobody has to grant it to them. An administrator can edit Baseline to widen or narrow that floor. Click New role to define a custom role instead. Its name, description, and permission set are all yours to change.
Granted instance-wide, at the bottom of a role's panel, lists the people, teams, and directory groups that hold the role everywhere on the server. This is the only way a role reaches global scope without a per-project attachment. It is the same grant you saw scoped to a project from a team's own panel above — leaving both fields empty here applies the role to every project at once.
You need the role.update permission atom, held globally, to create,
change, or grant a role.
Two related sections exist but are not in the People navigation:
-
Groups mirrors directory (AD) groups — the same groups a team can
link to, above. Reach it from Settings → Directory instead of a page
of its own.
/settings/groupsredirects there. -
Holidays, the per-team public-holiday list, lives in
Issue settings's Time logging section instead of here. It interrupts
the timesheet, not access, which is why it moved there.
/settings/holidaysredirects to Settings → Time logging.
Mirrored from project.radd-hq.com on 2026-09-12. Documentation is written there; this copy is regenerated by scripts/publish_wiki.py and hand edits do not survive it.