FileController

the fields a listing gives of a file (exportFile), for the schema it links to

Type

null | iPrivateKey

Type

null | iPublicKey

Make sure a request changing something comes from a page of the site: it has the session's token, or is authenticated by an Authorization header (which a browser does not send on its own)

A file as the routes give it to $user: what the page needs, nothing about the server (where the bytes are) nor about the owner (their title only), nor about the labels $user may not know -- a private tag of the owner, and the custom fields it defines. The custom fields (data) are columns too, but never replace one of the file's own.

The names of the files an archive left out, for <mmo-filemanager> to say which (my.oviepro #302): each one url-encoded (a comma, a letter that is not ascii, a line break are safe in a header), comma separated, as many as fit in $length -- X-Missing-Files says how many there are in all.

A file whose bytes are missing from the storage is left out (my.oviepro #292: the whole zip was a 500): the zip then holds a text file naming those left out, and says how many in its X-Missing-Files header, and which in X-Missing-File-Names (MissingFileNames). None left: 404.

Act on several files: {action, ids, labels} -- trash, restore, delete (from the trash), label or unlabel (labels: label ids). A file the user cannot act on is reported, the others are done.

Make a label: {label, parent, description, color, properties} -- without a parent, a tag of the user

The files the user can see

The tags of the current user, and the global ones: a tree of {value, label, title, color, path, children}

Get the schema associated to a list of labels

Start an upload: {name, size, labels, attachment, temporary} (labels: label ids, or quoted paths and "#tags", the user's own tags made if missing). The answer's id names it for the next requests.

The session's CSRF token (Token): a page holds the one of the session it was made in, which the server no longer has once the session changed (a new login, a page the browser restored), and MMO.edms.Api asks for it again when a request is refused for it. A GET is no risk: another site cannot read the answer (no CORS)

Send a chunk of the upload {id}: the body is its bytes, the header Content-Range: bytes {first}-{last}/{size} (or the query's offset) says where they go. The last chunk makes the file (file in the answer), unless the upload is temporary.

Upload a file in one request: a multipart body whose field file is the file -- what a form, or <mmo-editor upload-url>, sends. labels, attachment, name (the file's own name otherwise) and description come in the query or in the form's fields, so that an upload-url can say where its images go. The rights are those of a chunked upload (routeStartUpload), which stays the way for a file php would not take in one request (upload_max_filesize, post_max_size), or one to resume.

The url of the files' schemas document (routeSchemas), versioned like mmo.core's data/schemas.json (v=, SchemasVersion): the browser keeps it until the schemas of the files or of their labels change.

The file a temporary upload (temporary) of $user brought: the page sends its id back to the application, which takes the file -- to move or to delete, it is the caller's.

What an upload goes to, checked before its bytes are stored: the record it is attached to (whoever the application lets attach to it: FileManager::checkAttach), then its labels -- $user's own "#tags" made if missing -- in which $user must be allowed to put files.

The meta of the data api (mmo.core's RepositoryController) for a list sent whole, on one page: its total and its page, which a <mmo-table> or a <mmo-search> counts and pages by (my.oviepro #92)