docs / plm / Users and permissions

Users and permissions

Accounts and groups

Every person has an account with a username and password. Administrators create accounts and assign groups under Administration → Users and permissions, and can deactivate an account or sign a user out everywhere from the same page.

What an account may do is decided by its groups. The server checks five built-in groups:

Group	May
`viewer`	read everything an ordinary user can see; change nothing but their own workspace and preferences
`author`	create parts and revisions, check out their own work, edit uses lists, attributes, sourcing and attachments, start a review
`checkin`	release revisions, make a released or superseded revision obsolete, and break another user's check-out lock
`worker`	a headless CAD worker: take bake jobs and write their results, nothing else
`admin`	everything, including users, part types, categories, settings, scripts, backups and the audit log

An administrator is treated as a member of every group. A user can be in several groups; a typical engineer is author, a lead is author and checkin. Groups are plain names, so you can add your own (quality, purchasing) and use them as reviewers and in workflow permissions.

Signing in

In a browser you sign in with your password. The session lasts until it has been idle for session_idle_minutes (default 14 days) or session_max_hours after sign-in (default 30 days; 0 means no absolute limit). Both are server settings.

Under My account you can change your password (every other session of yours ends) and sign out everywhere.

Everything that is not a browser (the desktop CAD app, a bake worker, your own scripts) uses an API token, sent as Authorization: Bearer plm_…. Make one on the My account page. An administrator can make one for another user, such as a worker account. The token is shown once; the server keeps only a hash of it. A token can have an expiry, and can be revoked on the same page.

A token acts as its owner, narrowed by its scope:

Scope	May
`full`	everything its owner may
`read`	only read
`worker`	read, work the bake queue, and write documents: what a bake worker needs

No token can create or list tokens, change a password or sign out everywhere: those need the password.

The desktop CAD app can also sign in with a username and password. It then asks the server for a token and keeps the token, not the password. See Connecting the CAD app.

Five failed sign-ins for one username, or twenty from one network address, lock that username or address out for 30 seconds, doubling with each further failure up to 15 minutes. While locked out the server refuses without checking the password. Administrators see and clear lockouts on the Security page. The counts are kept in memory, so a restart clears them.

Server settings

Administrators set policy on Administration → Server settings. Each starts at the permissive choice.

Setting	Default	When on
Allow multiple open drafts	on	a part may have several revisions in work at once, each checked out separately
Lock released attributes	off	a released part with nothing in work refuses changes to its category and attribute values
Require released children	off	a revision cannot be released while any part in its uses list is not released
Workspaces browsable	on	anyone signed in may read (never change) another user's workspace; off, only the owner and administrators can
Script editor	on	administrators may edit scripts in the browser (always off with `--lock-script-editor`)
Session idle limit / maximum age	14 days / 30 days	see Signing in
Review rule and overrides	0 approvals	see Reviews and workflows

Security measures

Passwords are stored only as salted PBKDF2-HMAC-SHA256 verifiers.
Browser sessions use an HttpOnly, SameSite=Lax cookie, and every change must also carry the session's CSRF token.
Every page is served with a strict Content Security Policy (no inline script, no framing), X-Frame-Options: DENY, nosniff and Referrer-Policy: no-referrer; API answers are never cached.
Attachments download as files. Only raster images and PDFs may be shown in the browser.
See Running the server for TLS, proxies and Secure cookies.

The audit log

Every change the server commits is recorded in the audit log in the same transaction: who (user, and whether through a session, a token or the server itself), from which address, when, what record, the action (create, update, release, checkout, break-lock, document, sign-in, sign-in-failed, script-run, …) and each changed field before and after. A refused change logs nothing. Secrets are shown only as (secret). The log is never rewritten or pruned.