Usage and audit
Two pages answer “how much” and “who did what”. This page is for administrators of an application.
files.audit.readfiles.settings.manage- Quota bars for the application and for the whole tenant.
- Totals: stored bytes, renditions, open uploads, trash, number of files and versions.
- By kind (images, videos, documents, …) and by folder (the largest folders).
- The last 30 days: the application’s stored bytes and files per day, from a snapshot the service takes once a day. A day without a snapshot (before the first one, for example) is missing, never shown as zero.
Counting is explained on Quota and retention. The same numbers come from GET P/usage (with daily: [{ date, bytes, rendition_bytes, trashed_bytes, files, versions, quota_bytes }], oldest first) and, per application of the tenant, GET /tenants/:tenant_id/usage.
Audit log
Section titled “Audit log”files.audit.readEvery sensitive operation writes one row: uploads and new versions, renames and moves, metadata, status and visibility changes, trash and purge, legal holds (placed, changed, released), downloads of originals, access entries and inheritance, the role matrix, share links (created, opened, revoked, wrong passwords), settings and quotas. Reading metadata and previews is not logged; downloads are, one row per download link. Each row names the actor (a user, a backend client acting for a user, or the system), the target, the time and the address it came from. The complete list is on Audit actions.
- Filters: action, actor, target, dates.
- Export: the filtered rows as JSON lines, up to 100,000 rows per export.
- Rows are kept 365 days.
- Platform administrators read a tenant’s log across all its applications from platform administration; their reads and exports are recorded on the tenant, outside any application, so they do not appear here.
A file’s or folder’s own trail is on its Activity tab. From code: GET P/audit, GET P/audit/export, GET P/files/:file_id/audit and GET P/folders/:folder_id/audit.