Multi-Admin, Roles & Permissions

PicPeak supports as many administrator accounts as you need, each with its own login. What an account can do is decided by the role assigned to it, and a role is a named set of permissions you control.

Roles that ship

Six roles exist out of the box. All are marked as system roles, so none of them can be deleted, but all except Super Admin can be edited.

Super Admin is protected. It cannot be edited, and it automatically gains new permissions as features are added — the app re-grants anything missing on every start. That is deliberate: it guarantees at least one account can always reach everything, so an upgrade can never lock you out.

The two preset roles are frozen at the set of permissions that existed when they were introduced. They do not pick up permissions from later releases. Treat them as starting points to clone rather than roles that keep pace on their own.

The role editor

Users in the sidebar, then the Roles tab. It appears only for accounts that can manage roles.

From there you can create a role, clone an existing one and trim it, rename it, change its description, toggle individual permissions, and delete a role that no one is using. Each role shows how many permissions it holds and how many users have it.

The permission checkboxes are grouped by area — Events, Photos, Archives, Analytics, Email, Branding, CMS Pages, Settings & Config, Backup & Restore, Users & Roles, Activity Logs, Customers, Quotes, Invoices, Contracts, Accounting, Workflows, WhatsApp, System — with a select-all toggle per group.

A role’s key is fixed once created. The display name is not.

Guardrails

The editor stops you doing the things that would lock you out or let someone quietly promote themselves:

• Super Admin cannot be edited at all.
• You cannot edit your own role, unless you are a Super Admin.
• You can only grant permissions your own role already holds.
• Only a Super Admin can assign or invite another Super Admin.
• You cannot change your own role, demote the last Super Admin, or deactivate or delete the last Super Admin account.
• A role in use cannot be deleted until its users are reassigned.
• System roles cannot be deleted, and their names are reserved.

The dangerous-config split

settings.edit used to be one switch that opened every settings screen. It has been split so that a team member can manage everyday settings without being able to touch the things that move money, identity or access:

settings.edit keeps everything else.

Reading and writing are deliberately asymmetric. Viewing one of these screens needs either settings.view or the specific permission, so a role that could already see settings keeps seeing them. Changing anything needs the specific permission. In practice a role with plain settings.edit can open the security page and read it, but saving a change there fails.

The site URL is protected per field rather than per page: saving the General settings screen without altering the site URL works fine, and only an actual change to it requires settings.domains.

Assigning a role

Users tab → edit a user → Role. Invitations pick a role at creation time.

Changes take effect on the next request the server handles, so there is no need to re-issue logins. The affected person may need to reload the page before menus and buttons reflect their new role, because the browser caches the permission list for the session.

What a blocked action looks like

The admin interface hides controls you lack permission for rather than showing them greyed out, so a narrower role sees a smaller app rather than a wall of disabled buttons. Settings tabs are filtered the same way, and land on the first tab the account is allowed to open.

If a request is made anyway — through the API, or a stale browser tab — the server answers 403 with {"error": "Insufficient permissions", "code": "FORBIDDEN"}.

Upgrading from the fixed roles

Existing installs keep working. Admin, Editor and Viewer keep exactly the permissions they had, and the five new settings permissions are granted to any role that already held settings.edit, which in practice means Super Admin only.

What you will notice after upgrading:

• Two new roles, Solo Photographer and Team Photographer, appear in the list.
• A Roles tab appears under Users.
• Narrow roles may see fewer Settings tabs than before, because those tabs now have their own permissions.

New permissions from future features default to off for every role except Super Admin, so an upgrade never silently widens what your team can do.

Managing administrators

Users in the sidebar. Create accounts directly or send an invitation, set each one’s role, deactivate accounts that should no longer have access, and see who did what in the activity log.

The Users area itself is behind the userManagement feature flag, which is on by default.

Staying signed in

The login page’s Remember me box extends the session from 24 hours to 30 days, and exempts it from the idle timeout that would otherwise sign a quiet admin out within the hour. The 30 days are absolute, and the session still ends immediately on logout, on a password change, when the token is revoked, or when the account is deactivated.

Guest activity in the bell

The notification bell in the admin header surfaces what guests are doing: a gallery being opened, photos being downloaded by a guest or by a customer account, and photos being favourited.

These are deliberately debounced so a busy gallery does not flood the bell — one open notification per gallery per six hours, one single-photo save per gallery per hour. Slideshow traffic is excluded entirely. There are no per-type settings for this yet.

Related

• Admin SSO (OIDC) — sign in through an identity provider, with roles mapped from IdP claims.
• Customer Accounts — client-facing logins, which are entirely separate from admin accounts.