Who can do what

Every person on an install has one role: Owner, Admin, Developer or Viewer. Each role comes with a set of permissions. An Owner or Admin can change some of them for Developers and Viewers in Settings → Users & roles → Who can do what.

Every person signs in with their own email and password. A login is never shared.

What each role can do by default

There is exactly one Owner. An Admin can do everything except transfer ownership, change the Owner's account and change the mail server. The mail server is Owner only because it sends the password reset links of every account, the Owner's included.

A Developer works on the project, so the project's own settings are theirs: the ticket source and its token, notifications and their credentials, Bug Hunt and the design system. The repository connection, checks, budgets and guardrails, and everything about the install stay with Owners and Admins.

Every signed-in person can open Settings → General. A Developer sees the This install card and the Setup guide card there. The Who may approve card and Feedback to Reqursor show greyed out, because only the roles above can change them.

Changing what Developers and Viewers can do

In the Who can do what table, every permission is a row, grouped by area, with one column per role.

• A box you can click can be changed. Developers and Viewers have such boxes, and Admins have one for Approve and revert changes.
• A box you cannot click is fixed. It shows a check when the role has it and "Not included" when it does not.
• The Owner column never changes.
• Your changes stay on the page until you choose Save. They apply to everyone straight away, without anyone signing in again.
• Reset to Default brings back the table above.
• Every save is written to the audit log with who changed what.

What can never be granted

These rows are fixed, because they decide who controls the install:

• Adding and changing users.
• Managing the license and billing.
• Backing up, updating and restarting the install.
• Transferring ownership.
• Deciding what the install shares with Reqursor as feedback.
• The mail server.
• The basic read access every role has: tickets, runs, insights and projects, and the read only view of a project's files and a ticket's changes.

Rules that keep the table consistent

• Letting a role change install settings also lets it see them.
• Taking away the right to see install settings also takes away the rights to change settings and to store install wide keys and passwords.
• A Viewer can be given only two extras: seeing usage and spending, and seeing install settings. A Viewer can never change anything.
• API tokens are always cut down to what their owner can do right now, so a change in the table reaches existing tokens too.

Who may approve

Approve & commit a held change and Revert a shipped one need permission. By default that is Owners and Admins. You can add Developers in Settings → General → Who may approve. Both that card and the table's Approve and revert changes row edit the same setting. The Owner always keeps it, so an install can never lock itself out of approving.

Users

Add and manage people in Settings → Users & roles.

• Adding a user sets their first password. They change it under My account. Adding someone into a seat the license does not have is refused, with an Add seat option. See Users, seats and projects for what takes a seat.
• Deactivating a user ends their sessions and API tokens at once. Their history stays.
• Setting someone's password signs them out everywhere. Only the Owner can change the Owner's account.
• Transferring ownership makes an active Admin or Developer the Owner, and the old Owner becomes an Admin. It is the only way to get a new Owner.

Signing in

• Forgotten passwords. The sign-in page's reset link works when the install can send email and its public address is set. Mail goes through your own mail server or through Google. The Reqursor sends it option does not carry reset links. The Forgot your password page says which piece is missing. Set both up early, so nobody needs an admin to get back in. Without them, an Admin sets a new password in Users & roles, or whoever runs the server does it from a terminal with reqursor-dev admin reset-password <email>.
• Limits. Sign-ins are rate limited: after 5 failures on one account, or 20 from one address in 15 minutes, further attempts wait. A session ends after 12 hours without use, or 14 days after sign-in.

API tokens

For scripts and CI, create a token in Settings → API tokens and send it as Authorization: Bearer rdt_....

• A token is shown once, when you create it.
• It carries only some of your own permissions, and can never do more than you can.
• It expires: after 90 days by default, and after a year at most.
• It stops working when your role shrinks or your account is deactivated.
• Admins can list and revoke everyone's tokens.

The audit log

Each project's Audit page lists who changed what: every change made in the dashboard or with an API token, sign-ins and failed sign-ins, and credential changes. Nothing is ever deleted from it. See Users, roles and the audit log.

It shows 100 entries at a time, newest first, with a choice of 25, 50, 100 or 200 per page. You can page through the newest 10,000 entries that match your filters. Export Audit Log downloads every matching entry, including the ones past that limit, as a CSV file (oldest first, secrets masked). The export is itself recorded in the log.

• Users, seats and projectsWhat takes a seat, and how projects count against your plan.
• Users, roles and the audit logWhy an action might return a 403, and what is recorded.