Users and roles

Access is managed per site. Someone who can edit one client’s content has no access to another’s unless you add them.

Users

Open Users in the sidebar (requires users.manage).

The members table lists everyone on this site:

Column	Meaning
Email	The sign-in identity
Name	Display name
Role	Their single role
Can do	A summary of what the role allows

• Add user — enter email, name and role, then save.
• Remove — the ✕ at the end of a row.
• Save changes — commits edits to existing members.

Emails must be unique per site; adding an existing email updates that member instead.

Roles

Open Roles (requires roles.manage) to see and create roles. Each role is a name plus a set of capabilities.

Tick the capabilities you want, then save. The role becomes available in the Users role dropdown immediately.

Capabilities

Capability	Unlocks
content.read	See content lists and read records
content.write	Create, edit, publish and trash content
media.read	Browse the media library
media.write	Upload and delete media
schema.manage	Schema builder — content types and fields
plugins.manage	Install and configure plugins
users.manage	The Users screen
roles.manage	The Roles screen
*	Everything (super admin)

Why a role change needs a re-login

Your role and capabilities are embedded in the session token when you sign in. Changing a role does not retroactively rewrite an open session — the user must sign out and in before the new permissions take effect.

Enforced where?

The interface hides what you cannot use, and the server independently checks capabilities and site scope on every request. Hiding a menu is convenience; the server is the boundary.