> ## Documentation Index > Fetch the complete documentation index at: https://docs.yume.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Вложения > Универсальный механизм прикрепления комментариев, изображений, файлов и ссылок к любому объекту системы: привязка к любому объекту, изоляция по компании и хранение медиа в облачном хранилище. Модуль «Вложения» — это универсальный механизм прикрепления комментариев, изображений, файлов и ссылок к любому объекту системы. Связь устроена **универсально**: вложение не привязано заранее к конкретному виду сущности — родитель задаётся парой значений «тип объекта + идентификатор объекта». Благодаря этому один и тот же механизм работает одинаково для заказов, клиентов, товаров, единиц оборудования и любых других объектов. Каждое вложение обязательно принадлежит одной компании, а медиафайлы (изображения и документы) хранятся в облачном хранилище с поддержкой генерации миниатюр и прямой загрузки крупных файлов. ## Разделы Текстовые заметки с автором и контекстом; удаление — только автору или суперпользователю. Изображения в облачном хранилище с автоматической миниатюрой, поштучным и массовым добавлением. Произвольные файлы в облачном хранилище с определением расширения, поштучным и массовым добавлением. Прямая одношаговая загрузка крупных файлов в облачном хранилище через временную ссылку. Внешние веб-адреса, прикрепляемые к любому объекту; изменение и удаление — только автору или владельцу компании. ## Как всё устроено: привязка и изоляция по компании Все четыре вида вложений (комментарии, изображения, файлы, ссылки) построены на одном принципе. Вместо прямой ссылки на конкретную таблицу каждое вложение хранит пару значений: **тип объекта** (какой именно вид сущности) и **идентификатор объекта** (номер конкретной записи этого вида). По этой паре система вычисляет сам родительский объект по мере надобности — отдельного поля-ссылки на объект в базе нет. В программном интерфейсе тип объекта передаётся и возвращается **не числовым кодом, а по имени вида объекта** (текстовым названием). Это упрощает работу с API — не нужно знать внутренние числовые идентификаторы типов. То же имя используется и в фильтрах списков. Каждое вложение привязано к компании-владельцу, и все выборки автоматически ограничиваются компанией текущего запроса — увидеть или изменить вложения чужой компании через этот механизм нельзя. У этой автоматической фильтрации есть три служебных исключения, когда ограничение по компании **не применяется** и возвращаются все записи: * контекст компании не установлен; * вместо реальной компании задан технический (заглушечный) контекст; * контекст компании формально задан, но у него отсутствует идентификатор. Это служебное поведение, а не обычный пользовательский сценарий. Дополнительно: одновременная подгрузка данных о типе родительского объекта (оптимизация против лишних запросов к базе) выполняется только в той ветке, где выборка уже ограничена компанией; в «безкомпанийной» ветке этой подгрузки нет. Маршруты предусматривают четыре вида вложений плюс отдельную последовательность прямой загрузки крупных файлов. Массовое (пакетное) добавление доступно только для изображений и файлов; для комментариев и ссылок отдельного адреса массового создания нет. Полный перечень моделей и полей — в глоссариях соответствующих разделов. ## Особенности поведения (общие для всех видов вложений) Прочие особенности, о которых стоит помнить: * **Автоматическая фильтрация по компании отключается в служебных «безкомпанийных» ситуациях** (компания не задана, задан технический контекст либо у компании нет идентификатора) — тогда возвращаются все записи без ограничения. * **Удаление родительского объекта не гарантирует удаления прикреплённых к нему вложений** — связь вычисляемая; каскадно вложения удаляются только при удалении компании или самого типа объекта. * **Удаление самого вложения (изображения или файла) удаляет и объект в облачном хранилище**, а не только запись в базе — в отличие от удаления родительского объекта, здесь файл не остаётся осиротевшим.