Skip to content
CCS Files Docs

Media in Chat

CCS Chat stores the photos, videos and files that people attach to messages in the File Service, in the storage of the tenant application the conversation belongs to. Chat keeps only the file ids. This page explains where those files are, what you see of them as a Files administrator, and which of your settings decide what Chat accepts. How Chat’s users and backends attach files is on Chat’s own site: Attachments.

How Chat uses the File Service

Section titled “How Chat uses the File Service”

Chat is a platform application: one client of the service that works in every tenant application with Files switched on, as described in Contexts and tokens. You configure nothing for it. Chat checks who is a member of a conversation and which Chat permissions they hold before every call it makes here, then creates the upload tickets, completes them and mints the URLs for its users. Chat’s apps send the bytes straight to the store with the ticket, and need no File Service token.

When the application has Files switched off, Chat’s attachment routes answer an error of Chat’s own and Chat keeps working for text. A suspended tenant keeps its files readable, and new attachments are refused.

Where the files are

Section titled “Where the files are”
Item What Chat creates
The chat folder One folder at the root of the application, named chat, with the external reference chat:root. It does not inherit access from above
A conversation folder One folder inside it per conversation, named after the conversation’s id, with the external reference chat:conversation:<conversation_id>, created with the conversation’s first attachment. It does not inherit either. Its owner is the user who created the conversation
The folder’s access entries One access entry with view and download for each active member of the conversation. Chat adds one when someone joins and removes it when they leave or are removed
A file Owned by the member who sent it, private, with the conversation’s external reference. A duplicate name is renamed, such as IMG_5913 (1).jpg

A member reaches the files of their conversations only, and only while they are a member. The service applies these entries to every read, so a member who opens Files directly with a token of their own sees no more than Chat shows them.

Chat’s folders become application-managed folders once Chat moves to the library version that carries the mark (ccs-files-client 1.3.0). The chat folder and everything below it are then read-only for people, the console shows them as managed by Chat, and a change by hand is refused instead of being undone later; the tenant owner can still release the folder in an emergency. Until then, the caution above applies.

What Chat accepts: the chat upload policy

Section titled “What Chat accepts: the chat upload policy”

Every Chat upload asks for the upload policy named chat. You decide what it allows on the Settings page of the console, or from a backend with files:config.manage:

Permission: files.settings.manage
  • With a chat policy, Chat accepts the types and the largest file size it lists, for example image/* and video/* up to 500 MB. A policy never allows more than the application itself.
  • Without one, the application’s own allowed types and largest file apply, as for any other upload. Every type is allowed until you narrow it.

Chat reads the policy for its users and shows it to their file picker, and the service enforces it on every ticket. A type outside it, or a file whose bytes turn out to be another type, is refused; a file above the size is refused before any byte is sent. Chat answers its users with errors of its own, never with the service’s codes. See Uploads.

Scanning, renditions and quota

Section titled “Scanning, renditions and quota”

Chat’s files are ordinary files of the application, so every setting applies to them as to any other:

  • Malware scanning runs on each of them, under the application’s scan policies. While a file waits for a clean scan, or after it was quarantined, Chat shows it as not available; a quarantined file is never served. See Malware scanning.
  • Renditions are made as usual: Chat shows the thumbnail and preview of images and of a PDF’s first page, and a video’s poster and its playable mp4_720p. With renditions switched off, Chat shows the originals. See Previews and renditions.
  • Image metadata is removed or kept as the application decides, and type checks and text extraction run as configured.
  • Quota. Chat’s files count against the application’s storage quota and the tenant’s, like any upload, the files in the trash included. A full quota refuses new attachments until usage drops. GET P/folders/:folder_id/usage answers the usage under one conversation’s folder. See Quota and retention.

The trash

Section titled “The trash”
In Chat In the File Service
A message with attachments is deleted Its files move to the trash
A conversation is deleted Its folder moves to the trash, with every file in it
A file was uploaded and never sent It moves to the trash after a day

Trashed files stay restorable for the application’s trash retention (default 30 days), then are purged. Restoring a file brings it back in Files only: the deleted message stays deleted in Chat.

What you see in the console

Section titled “What you see in the console”
  • Browse shows the chat folder and the conversation folders, with each file’s owner, size, processing and scan outcome. See Browse and upload.
  • Usage and audit shows what Chat stores, and the audit log has a row for each upload, access entry, trash and download link of an original that Chat makes, with Chat’s client as the actor and, for uploads, the member it acted for. See Usage and audit.
  • Search finds Chat’s files like any other file, under the same permission rules.
Section titled “Related”