Permissions page

Permissions is where the tenant owner decides, for each role, what it may do with files in an application: the system level of the permission model. The decisions are stored at the Identity Server with your roles. This page is for tenant owners and the people they delegate to.

Prerequisite: the CCS Identity Server.The File Service runs on your Identity Server. It owns your users, tenants, applications, roles, clients and tokens; the service owns none of them.

Your role needs the permission for the page, granted by the tenant owner on the console's Permissions page, and Files must be switched on for the application. See who can open which page.

New to it? Read the Identity Server documentation (opens in a new tab).

Who may open it

The tenant owner always, and holders of files.permissions.manage. Only the owner may give files.permissions.manage to a role or take it away (tenant_owner_required); the owner’s own row cannot be changed (role_locked), because the owner holds everything.

The matrix

One row per role that may carry Files permissions (your tenant roles and the application’s own roles), one column per key, in two groups:

Group	Keys
Content	View, Download, Edit, Share, Delete, Approve, and Full content access (files.manage): everything on every file and folder
Administration	Settings (files.settings.manage), Audit log and usage (files.audit.read), and Full administration (files.configure): both
Delegation	Manage permissions (files.permissions.manage): this page. The owner-only column

Ticking an umbrella key ticks what it contains. A row shows what the role holds now; save each change explicitly. Changes are rate limited to 30 per minute, and every saved change is in the audit log as permissions.updated.

What the keys grant is on Permissions. They apply to everything in the application; folder and file entries add to them, never take away.

All applications

The All applications view shows a tenant role’s keys in every application you may manage, side by side: Same everywhere or Differs. Applying a row there writes it to every application, and reports per application whether it was applied, failed or skipped. It covers tenant roles only (application roles belong to one application) and at most 50 applications.

The routes behind the page: GET P/permissions, PUT P/permissions/roles/:role_id, GET /tenants/:tenant_id/permissions and PUT /tenants/:tenant_id/permissions/roles/:role_id. They take user tokens only.

Typical setups

Application	Mapping
A social app whose backend writes everything	Nothing for member: each member sees their own uploads and what the backend made visible
A team space	member: View and Download; a team-lead role: Full content access
A document library with review	member: View, Download; editor: Edit; reviewer: Approve; librarian: Full content access; an admin role: Full administration

The Identity admin UI

The same mapping can be edited in the Identity Server’s admin UI, under the tenant’s role permissions. That UI does not yet enforce the owner-only rule for Manage permissions on its own. Until it does, treat anyone who may edit roles there as able to change the Files mapping too.