Задача
Инженерная документация стареет иначе, чем маркетинговая. Compatibility document действителен для конкретной пары «железо — прошивка». Discontinuation notice должен оставаться доступным и после снятия продукта с производства, потому что у клиента это оборудование ещё работает. Technical support показывает заказчику документ и отвечает за то, что документ утверждён, а не найден в чьей-то папке.
Файловое хранилище на эти вопросы не отвечает. Оно не знает, последняя ли это версия, прошла ли она review, можно ли отдать её дистрибьютору и кто именно скачал её в прошлом квартале. Отсюда обычный набор последствий: у поддержки и у инженеров расходятся представления о том, какой документ актуален; обучающие материалы собираются копированием файлов и перестают обновляться; закрытый документ уходит наружу вместе со ссылкой.
Нужна была система, где структура библиотеки, метаданные, версии, согласование и права — части одной модели, а не соглашения между людьми.
Решение
Структура библиотеки. Разделы построены под содержимое заказчика: Applications, Delivery Status, Development information, Products и Training Material. Development information внутри разложена по направлениям Hardware, Firmware, IDE и NC. Хлебные крошки показывают принадлежность документа продукту и разделу — определять смысл по имени файла больше не нужно.
Один актив — несколько коллекций. Материал включается в разные подборки без копирования оригинала. Один и тот же release note может лежать и в продуктовой ветке, и в обучающем наборе, оставаясь одним активом с одной историей версий: обновление в одном месте не оставляет за собой устаревшие дубликаты в других.
Карточка актива. Связывает оригинальный файл, preview, метаданные, версии, владельца, права, статус и историю действий. При загрузке заполняются название, описание, тип, продукт, категория и теги; формат и дата создания подтягиваются сами. Часто используемое отмечается как Favorite, несколько файлов выбираются для группового скачивания или передачи.
Поиск. Глобальный поиск идёт по названию и индексируемым метаданным, результаты сужаются по типу контента — Photos, Documents, Videos — и по структуре библиотеки. Для технической базы принципиальны поиск по части имени файла и по product identifier, приоритет точного совпадения и хлебные крошки до исходной папки. Права сохраняются в выдаче: закрытый файл не появляется в результатах и не открывается по прямому URL.
Preview как производное представление. Поддерживаемые документы открываются во встроенном viewer без обязательного скачивания, оригинал при этом не меняется. Ошибка конвертации не уничтожает загрузку: файл получает понятный processing state и может быть обработан повторно — вместо «документ не открылся, загрузите заново».
Версии и approval. Обновление технического документа создаёт новую версию существующего актива, а не второй файл: в истории остаются автор, время, комментарий, статус и связь с предыдущим вариантом. Жизненный цикл — Draft → In review → Changes requested или Approved → Published → Superseded или Archived. Approval относится к конкретной версии, поэтому новая загрузка не подменяет незаметно ранее утверждённый материал. Критичные документы вроде discontinuation notices сохраняют опубликованную историю и связь с заменяющим продуктом или последующей версией.
Права. Задаются на раздел, папку, коллекцию или отдельный актив, и по отдельности: просмотр, загрузка, изменение метаданных, создание версии, approval, скачивание, sharing, администрирование. Sales, дистрибьютор или партнёр видят разрешённое, инженер публикует в своё направление, reviewer утверждает, администратор управляет справочниками и обработкой файлов.
Sharing и delivery status. Передача файла или набора фиксирует инициатора, получателей и выбранную версию, а права проверяются при каждом открытии ссылки, а не один раз при отправке. Delivery Status — отдельное операционное представление для материалов и пакетов, ожидающих публикации, передачи или другого следующего действия. Уведомления сообщают о новой версии, запросе на review, возврате на доработку, approval и публикации, выдаче доступа, изменении delivery status и ошибке фоновой обработки.
Асинхронная обработка. Symfony-приложение разделено на доменный слой DAMS, файловое хранилище, поисковый индекс, preview workers, workflow согласований, уведомления и административный контур. Крупные загрузки и конвертация выполняются в фоне, чтобы интерфейс не ждал обработку тяжёлого файла.
Аудит. Журнал входов, загрузок, скачиваний, изменений и решений позволяет восстановить, кто загрузил, изменил, утвердил, скачал или передал конкретную версию.
Результат
У технической документации появился один адрес. Support, инженеры, обучение и партнёры смотрят на одну библиотеку и на одну и ту же утверждённую версию документа, а не на почтовые вложения разной свежести.
Публикация стала контролируемой: материал проходит review, утверждается по версии, а прежняя версия помечается как superseded и остаётся в истории — важное свойство для документов, которые нужны и после снятия продукта с производства.
Распространение перестало быть дырой в периметре: доступ проверяется при каждом открытии, sharing именной, а всё скачанное и переданное видно в журнале.
