Лицензия ADWOS CMS

Лицензия ADWOS CMS подтверждает право использовать платформу на конкретном проекте и управляет доступом к обновлениям, модулям, закрытым возможностям и поддержке. Для владельца это не техническая формальность, а контрольный центр: активен ли проект, доступно ли обновление, корректно ли привязан домен и нет ли ограничений по тарифу или периоду поддержки.

Что проверяет лицензия

• Статус проекта: активна ли лицензия и разрешена ли работа текущей установки.
• Домен: совпадает ли рабочий адрес сайта с доменом, который закреплен за лицензией.
• Период поддержки: доступны ли обновления, помощь и закрытые материалы по текущим условиям.
• Доступ к возможностям: какие модули, API-разделы и функции открыты для этой установки.

Что важно владельцу

• Перед сменой домена проверьте лицензионную привязку, чтобы после переезда сайт не потерял доступ к обновлениям и модулям.
• Перед покупкой или продлением тарифа уточните, какие возможности входят в условия: обновления, модули, API, поддержка, тест-драйв.
• Если сайт передается другой команде, отдельно передайте информацию о лицензии, домене, ответственном владельце и канале поддержки.
• Не смешивайте лицензию с правами администраторов: лицензия открывает возможности продукта, а роли админ-панели ограничивают действия сотрудников.

Как работает с обновлениями

• Штатное OTA-обновление ADWOS CMS само создает техническую резервную копию перед установкой.
• После установки выполняется проверка работоспособности: если проверка не проходит, система автоматически откатывает файлы и базу данных к предыдущему рабочему состоянию.
• Владельцу не нужно вручную создавать отдельную копию перед каждым штатным OTA-обновлением; важно следить, что обновление запускается из официального раздела и лицензия активна.
• Если обновление недоступно, проверьте статус лицензии, минимальную требуемую версию и период поддержки.

Где проходит граница ответственности

• Массовый импорт и ручные миграции относятся к операциям с данными: их нужно проверять на тестовом наборе и выполнять по регламенту.
• Работа напрямую с базой данных, файлами или сервером находится за пределами обычного OTA-сценария.
• Нестандартную миграцию домена, хранилища, почты, платежей или внешних интеграций лучше планировать отдельно от штатного обновления.
• Плановое резервное хранение нужно не вместо OTA, а для аварийных сценариев вне обновления платформы: ошибок импорта, ручных работ, инфраструктурных сбоев и восстановления файлов.

Частые ошибки

• Считать, что неактивная лицензия влияет только на поддержку. На практике она может ограничить обновления, закрытые материалы и часть интеграционных сценариев.
• Менять домен, не проверив лицензионную привязку.
• Путать автоматическую защиту OTA с полной стратегией резервного хранения проекта.
• Передавать подрядчику административный доступ без понимания, кто отвечает за лицензию и обновления.

Правильная логика простая: лицензия отвечает за право и доступ, OTA отвечает за безопасное обновление, а регламент резервного хранения отвечает за аварии, импорт и нестандартные работы.