Modules
The tenant file library, its folders and its sharing model. Core.
files is the tenant's own library at /files: folders, files, versions and shares, with the bytes in the tenant's storage and the metadata in its database.
| Table | Holds |
|---|---|
file_folders | The folder tree, with a maintained ancestor path for subtree tests. |
files | A catalogued record: name, folder, bucket, type, size, uploader, visibility, current version. |
file_versions | One immutable object key per upload. |
file_shares | A person and a share role on one file or one folder. |
Folders are rows, not storage prefixes, so a move is one update and nothing in the bucket ever moves.
| Visibility | Who can open the bytes |
|---|---|
private | The uploader, plus explicit sharees. |
internal | Anyone holding the read permission. |
public | The storefront and anonymous visitors. |
A share names a person and a role, viewer or editor, on a file or a whole folder subtree. Visibility is fixed at first upload, because it is which bucket the key lives in.
An admin sees the row of a private file, so the storage meter, the bin and the audit trail can count what they may not open. They cannot rename, move or trash it, cannot grant themselves a share, and cannot reach the bytes: the object key is released only by a database function that re-applies the row rules, and the generic download actions refuse the library's buckets. Reaching a departing employee's files is an audited ownership transfer.
The limit is honest: this keeps a colleague out of the app path, not out of a backup or the storage credential.
/files: a folder rail with scope links and a storage meter, breadcrumbs, and a switchable list or card view.
files.read and files.manage. By default only the admin role holds them.
Never. Every project links it at provisioning.