Platform administration
Platform administration is outside any tenant: it is where Central Code Station’s platform administrators see how much each tenant stores and how fast it grows, set what each tenant may store, read a tenant’s audit log, export reports, and decide where each tenant’s files are stored. It opens for users the Identity Server reports with its platform administrator role, and for nobody else (platform_admin_required). This page is for those administrators.
Tenants
Section titled “Tenants”Every tenant with its usage against its quota, largest first, searchable by name, with badges for suspended and over-quota tenants. A tenant’s page shows its applications’ usage, its last 30 days, the tenant’s settings, a link to its audit log and the usage export:
| Setting | Effect |
|---|---|
| Quota | The bytes all the tenant’s applications may store together, or unlimited. Lowering it below the usage deletes nothing and blocks new uploads |
| Largest file | A ceiling for every application of the tenant, within the platform maximum of 5 GiB |
| Allowed types | A ceiling on the types any application may accept, or none |
| Public files, share links | Whether the tenant’s applications may use them at all |
| Suspended | Every new upload and version answers tenant_suspended; reading keeps working |
| Note | Free text for other administrators |
Where the tenant’s files are stored is on its own page: Storage accounts.
Usage trends
Section titled “Usage trends”The Usage trends page ranks the tenants and sums the platform:
- Totals: tenants with files, bytes and files stored now, tenants over their quota, and tenants at 90% of their quota or more, with the platform’s bytes per day.
- The ranking: each tenant’s bytes stored now, its share of the quota, its change over the window and a small chart per day. Rank by stored now (the largest tenants), by growth (the last day of the window minus the first) or by quota pressure (stored and reserved bytes over the quota; unlimited tenants come last).
- The window: up to 90 days days.
The trends come from daily snapshots: once a day the service records each application’s and each tenant’s bytes, renditions, trash, open uploads, files, versions, bytes by kind and the quota in force. Snapshots are kept 400 days. A day without a snapshot (before the first one, for example) is missing from every series, never shown as zero. “Stored now” and the quota share are live; growth compares snapshots.
A tenant’s own trend reaches back up to 400 days, for the tenant and for each application. An application’s administrators see their own last 30 days on their usage page.
A tenant’s audit log
Section titled “A tenant’s audit log”Audit log of this tenant shows every application of the tenant at once, plus the tenant-level rows that belong to no application: changes to the tenant’s settings and quota, and the platform’s own reads and exports. It has the filters of an application’s audit log (action, actor, target, dates) plus the application, newest first.
Every read is itself audited (tenant_audit.read, with the filters and the number of rows), on the tenant and outside any application, so a tenant’s own audit pages never show it. Platform administrators read it here.
Exports
Section titled “Exports”| Export | Holds | Bounds |
|---|---|---|
| A tenant’s audit log | The filtered rows, newest first, as NDJSON (one audit row per line) or CSV (metadata as JSON in one column) |
At most 100,000 rows; the export says when the filters matched more |
| A tenant’s usage | The daily snapshots of a period: one row per day for the tenant and one per application and day, with bytes by kind | A period of at most 400 days |
Exports download as files and never contain file bytes, extracted text, tokens or passwords. In CSV, a cell that a spreadsheet would run as a formula (one starting with =, +, -, @, a tab or a carriage return) is prefixed with '. Each export is audited before its first row is written (audit.exported with the format, the filters and whether it was cut; usage.exported with the period), and rows written after it started are not part of it.
Platform defaults
Section titled “Platform defaults”The quota a new tenant starts with (default 50 GiB), the default largest file, and the default allowed types.
Every change is audited with the administrator and the values before and after (tenant_settings.updated, platform_settings.updated).
From code
Section titled “From code”| Route | Answers |
|---|---|
GET /platform/tenants, GET /platform/tenants/:tenant_id, PUT /platform/tenants/:tenant_id/settings |
The tenants, one tenant, its ceilings |
GET /platform/settings, PUT /platform/settings |
The platform defaults |
GET /platform/usage |
?days=&sort=&limit= (sort used_bytes, growth_bytes or quota_ratio; at most 100 tenants): { days, from, to, sort, totals: { tenants, used_bytes, files, over_quota, near_quota, daily }, items }, each item with used_bytes, start_bytes, growth_bytes, growth_ratio, quota_ratio and daily. A ranking, not a paged list |
GET /platform/tenants/:tenant_id/usage |
?days=: { tenant_id, name, days, from, to, daily, applications: [{ application_id, name, daily }] } |
GET /platform/tenants/:tenant_id/usage/export |
?from=&to=&format=ndjson|csv (UTC days, default the last 30) |
GET /platform/tenants/:tenant_id/audit |
The filters of GET P/audit plus application_id, paged |
GET /platform/tenants/:tenant_id/audit/export |
The same filters and format=ndjson|csv; the X-Export-Truncated header says whether the row cap cut it |
A day of daily is { date, bytes, rendition_bytes, trashed_bytes, files, versions, quota_bytes }. A bad days, period, format or sort answers invalid_request. The routes take a platform administrator’s user token, or a machine token with files:config.manage of a client of the Files platform application itself; a tenant’s client never passes. The ccs-files-client library has them as platform (ccs-files-client).