Roles and Access

Roles and Access

Plum has two levels of permission: an account role (User.role) and a per-project membership.

Account roles

Role	Reach
owner	Every project and every setting, account-wide. Manages users, runners, backup, and creates projects. There is exactly one owner (the first account created).
admin	Full settings, but only for the projects they are assigned to. Cannot create projects, manage users, runners or backup — but can reset a user's password (see below).
user	The projects they are assigned to. No settings access.

The owner is an implicit member of every project — it never needs to be added to one.

What each role sees

• Automated Tests, Reports, Scheduled, Test Repository, run bar — any member of the project.
• Settings → Project / Integrations / Test Cases / Activity Logs — owner, or an admin assigned to that project.
• Settings → Organization / Runners / Backup, and creating or deleting projects — owner only. An admin's reach stops at its assigned projects.
• Settings → Users — the owner gets the full page (add, remove, change roles, auto-logout). An admin gets a cut-down version: the list of users with a Reset password action, nothing else.
• Recording a manual result, claiming a case in a test run — any member.
• Running an AI Analysis and opening its fix PR — any member with access to the project. Connecting the AI provider keys and the GitHub token themselves stays owner-only (Settings → Integrations).

Per-project membership

Add people from Settings → Users (owner). For each person you set:

• an account role (admin or user), and
• which projects they belong to.

A user or admin with no project assignments sees an empty Plum. The project picker only lists projects the current account can reach.

Password resets

Settings → Users has a Reset password action on each row it shows:

• An owner can reset an admin or a user.
• An admin can reset a user.
• Nobody resets an owner this way — an owner changes their own password under Settings → Account.

The reset generates a random temporary password shown once. Copy it and hand it over; the person changes it under Settings → Account after signing in. The old password stops working immediately.

Organization identity

Settings → Organization (owner only) holds the name and logo URL you entered when Plum was installed. Both are editable here.

• The name and logo show on the login screen.
• When a logo is set it also replaces the Plum wordmark in the navbar; with none set, both fall back to the wordmark.
• The logo is referenced by URL — host the image yourself (a CDN, an S3 bucket); there is no upload.
• Changing the name is safe: nothing is keyed on it, it is a display string only.

Both travel with a backup, so a restore keeps them.

Sign-in options

Settings → Users → Sign-in options (owner only) chooses how people sign in, org-wide:

• Email & password — the built-in form. On by default.
• Sign in with Google — off until configured. See Google Sign-In for the full walkthrough.

At least one method is always on — Plum won't let you disable the last one. Both can be on at once; the login screen then shows the form and a Sign in with Google button. Google sign-in only works for an account an owner has already added — there is no automatic account creation.

Auto-logout

Settings → Users → Auto-logout (owner only): 6, 12, 18 or 24 hours. A session older than this is ended and the person is returned to the login screen. The limit is fixed into each session when the person signs in, so a change only affects logins made after it is saved.

Result history survives removal

Manual test results and activity entries store the person's name as it was at the time. Removing someone from a project — or deleting the account — leaves their past results and audit trail intact.

API keys

• PLUM_MCP_KEY (an environment variable on the server, for CI) authenticates as the owner, instance-wide.
• A per-member MCP key minted in Settings → API & MCP authenticates as that member, with that member's role, pinned to the project it was created in. See MCP Integration.
• The registration secret (PLUM_NODE_SECRET) is not a user; it only authorises a node to register and be controlled. See Setting Up Nodes.

Anything created or run through a key is attributed <name> (MCP) in the Activity Logs and on the rows it touches.