Задача
Маркетологи, дизайнеры, бренд-менеджеры и согласующие работают с одними и теми же материалами, но с разными задачами и разной ответственностью. Пока файлы живут во вложениях, никто не отвечает на простые вопросы: какая версия утверждена, кто её утвердил и на каком основании, не ушёл ли в подготовку устаревший исходник, у кого есть право скачать оригинал. Нужен был корпоративный источник истины по брендовым материалам, где каждое решение можно проследить.
Решение
Ядро и адаптация. Проект опирался на отработанное продуктовое DAMS-ядро. Оно отвечало за хранение и каталогизацию файлов, папки, коллекции и метаданные, версии и статусы готовности, ролевой доступ. На нём же работали согласование и комментарии, контролируемое скачивание и распространение, подготовка материала в редакторе, постановка утверждённого файла в очередь и административные настройки с аудитом. Под Green Dot настраивались фирменное оформление, структура библиотеки, роли, метаданные, статусы и маршруты согласования. Получилось отдельное внедрение с собственной конфигурацией и своей средой эксплуатации.
Права до уровня отдельного актива. Доступ задавался на уровне раздела, папки и отдельного файла. Для папки или файла раздельно выдавались просмотр, загрузка, редактирование метаданных и создание версии, а также согласование, скачивание, распространение и административные действия. Проверка выполнялась на сервере, поэтому прямая ссылка на закрытый оригинал не открывала его в обход прав.
Библиотека. Пользователь создавал и переименовывал папки, собирал один материал в разные коллекции без дублирования исходника, загружал отдельные файлы и наборы, видел превью поддерживаемых форматов. К файлу заполнялись название, описание, тип, кампания, категория и теги. Искать можно было по названию и метаданным, фильтровать — по формату, статусу и принадлежности, выделять несколько файлов для группового действия. Карточка актива связывала файл с метаданными, версиями, владельцем, статусом, комментариями и историей действий, поэтому утверждённый материал не терял контекст при перемещении между папками или передаче другому сотруднику.
Версии и жизненный цикл. Новая загрузка становилась очередной версией существующего актива. Сохранялись автор, время изменения, комментарий и связь с предыдущим вариантом, состояния можно было сравнить и вернуться к нужному. Цепочка выглядела как Draft → In review → Changes requested / Approved → Ready for use → Archived. Утверждение относилось к конкретной версии: если дизайнер загружал обновление уже после согласования, новый вариант снова шёл на проверку, а ранее одобренный файл оставался зафиксированным. Разделы Approved files, Files in queue и Job status отделяли готовое от того, где ещё требуется действие.
Согласование. Материал уходил на проверку из библиотеки или редактора, и в запросе фиксировались выбранная версия, инициатор, согласующий, комментарий и текущий этап. Проверяющий открывал превью или макет на согласование, оставлял замечание, подтверждал готовность, возвращал на доработку или переадресовывал задачу уполномоченному участнику. Уведомления сообщали о новом запросе, комментарии, возврате и утверждении, зависшие и просроченные задачи были видны в очереди, а административный журнал позволял восстановить, кто и на каком основании принял решение.
Редактор макетов. Отдельный редактор работал с холстом и сторонами изделия: текст и изображения, собственные загрузки или файлы из библиотеки DAMS, отмена действий, масштабирование. Сохранение создавало связанную версию. Перед дальнейшей обработкой система готовила превью или макет на согласование, а команда Order File передавала выбранный и проверенный результат на следующий внутренний этап.
Очередь подготовки (Print queue). Очередь была внутренним продолжением DAMS, а не магазином: утверждённый актив или подготовленный макет попадал в рабочую корзину, после чего создавалось задание, привязанное к конкретной версии файла, с названием, инициатором, материалом, состоянием и комментариями. Эта привязка исключает ситуацию, когда в дальнейшую подготовку случайно уходит неутверждённый или устаревший исходник.
Архитектура. Серверная часть — Symfony. Ответственность разделена между частями: приложение DAMS с карточками, папками, метаданными, версиями и правами; файловое хранилище с оригиналами и производными представлениями; фоновые процессы загрузки, извлечения базовых свойств и генерации превью; модуль процессов со статусами, согласованиями, заданиями и уведомлениями; редактор; администрирование. Крупные операции с файлами выполнялись асинхронно, чтобы не блокировать интерфейс. Повторная обработка не должна была порождать лишнюю версию или второе задание: ошибка сохраняла понятный статус и допускала безопасный повтор.
Аудит. История связывала с пользователем, активом и версией каждое действие: входы, загрузки, решения, скачивания и изменения прав. Изменения справочников и прав не переписывали историю уже согласованных материалов: в журнале оставался контекст, действовавший в момент решения.
Результат
У Green Dot появилось собственное внутреннее пространство для брендовых и маркетинговых файлов. Сотрудники работали с общей структурированной библиотекой, отличали рабочие версии от утверждённых, согласовывали материалы в системе и передавали дальше по процессу зафиксированный файл. Ссылка на актуальный актив заменила вложения в переписке, скачивания и распространение попали в историю, устаревшие материалы больше не всплывали в обычной выдаче. Операционные отчёты показывали состав библиотеки, активы без обязательных метаданных и загрузку очередей согласования.
Для нас это стало и продуктовым результатом: проверенное DAMS-ядро оформлено как повторно используемая основа, которая разворачивается под нового заказчика вместе с его ролями, метаданными и маршрутами.
