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