Перейти к основному содержанию

Changelog

Около 3 мин

Changelog

В это разделе (левое меню) автоматически публикуются ссылки на новые сборки enterprise-версии. Актуальной считать версию от ближайщей даты. Если таких несколько - то с более высоким индексом.

Можно обновляться на несколько версий сразу, если не указано иного. Ниже на странице — лента релизов со всеми версиями; сначала прочитайте предупреждения об обновлении.

⚠️ С версии 6.6.XXXX доступен переходный режим лицензирования v1/v2

6.6.XXXX — блокирующий выпуск placeholder: перед публикацией релиза его необходимо заменить на фактический номер версии. Пока номер не подтверждён, не подставляйте предполагаемую версию.

Начиная с версии 6.6.XXXX существующий LICENSE_KEY временно продолжает работать: немедленно менять конфигурацию или перевыпускать ключи для всех инсталляций не требуется. Лицензии v1 устарели и имеют известное ограничение безопасности, поэтому планово переводите каждую инсталляцию на отдельный LICENSE_KEY_V2.

Если задан непустой LICENSE_KEY_V2, используется только он. Неверный v2 не вызывает автоматический возврат на LICENSE_KEY.

Мигрируйте инсталляции постепенно:

  1. Составьте список всех инсталляций: production, тестовых контуров, резервных площадок (DR) и клонов.
  2. На каждой работающей инсталляции откройте /admin-onboarding (например, https://ваш-домен/admin-onboarding) и скопируйте весь код активации без сокращения. Вход не нужен, мастер настройки запускать не надо. Код не зависит от версии образа (страница есть с 6.6.2310, ручка GET /api/v1/license-signature — с 6.6.2229), поэтому его можно снять до обновления — см. «Где взять код активации на существующей инсталляции».
  3. Передайте полный код менеджеру и получите отдельный LICENSE_KEY_V2 для этой инсталляции. Затем обновите инсталляцию до версии с поддержкой v2, сохранив рабочий LICENSE_KEY.
  4. Добавьте LICENSE_KEY_V2, не удаляя LICENSE_KEY до проверки и окончания согласованного окна отката.
  5. Перезапустите все экземпляры, убедитесь, что в них задан полученный LICENSE_KEY_V2, дождитесь health checks и проверьте на /admin-onboarding состояние лицензии. Затем проверьте доступ обычного пользователя и нужные модули AI/DES: в v2 оба разрешения по умолчанию выключены и должны быть согласованы при выдаче ключа.
  6. После успешной проверки и окончания окна отката удалите LICENSE_KEY из рабочей конфигурации этой инсталляции. Остальные инсталляции могут временно продолжать работу с v1 до своего окна миграции.

Один ключ нельзя переносить между инсталляциями. Отдельный ключ нужен для production, каждого тестового контура, DR-площадки и каждого клона.

Если задан неверный LICENSE_KEY_V2: наличие рабочего LICENSE_KEY не включает fallback. Исправьте v2 либо удалите или очистите его для возврата к v1, затем перезапустите все экземпляры приложения. Бэкенд может работать в заблокированном лицензионном режиме, чтобы владелец — учётная запись из администраторской команды — мог открыть /admin-onboarding и пройти восстановление. Данные при этом не теряются; успешный health check сам по себе не подтверждает лицензированный доступ обычных пользователей.

Подробнее — в разделе «Активация инсталляции».

⚠️ С версии 6.6.5952 требуется расширение PostgreSQL `pgvector`

Начиная с версии 6.6.5952 (от 09.06.2026) расширение pgvector — обязательное требование платформы: на нём работает быстрый универсальный (семантический) поиск по вашим данным — это нужно всем установкам, независимо от наличия AI-модуля. База знаний AI-чата — лишь один из потребителей этого движка, а не причина требования.

Без расширения миграция базы не выполнится и бэкенд не запустится (мягкой деградации нет). Версии до 6.6.5694 включительно расширение не требовали — при обновлении с них подготовьте PostgreSQL до смены версии приложения:

  1. Переведите PostgreSQL на сборку с pgvector — например, образ pgvector/pgvector:pgXX под вашу мажорную версию PostgreSQL (pg15/pg16/pg17); для enterprise доступно внутреннее зеркало cr.selcloud.ru/stormbpmn-enterprise/pgvector:pg17. Либо установите пакет расширения в текущую СУБД (например, postgresql-17-pgvector) и перезапустите её. Для управляемых БД (DBaaS) убедитесь, что провайдер предоставляет pgvector.
  2. Заранее заведите расширения в базе приложения (от суперпользователя или роли с правом CREATE EXTENSION):
CREATE EXTENSION IF NOT EXISTS vector;     -- pgvector, обязательно с 6.6.5952
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS hstore;
CREATE EXTENSION IF NOT EXISTS pg_trgm;     -- автодополнение пользователей (приложение не создаёт его само)

Подробности и порядок обновления — в описании версии 6.6.5952. Полный список расширений, кодировку БД и рекомендации по образу см. в разделе «Требования к PostgreSQL». Про саму базу знаний — «База знаний AI-чата».

Примечание

С версии >6.6.1861 серьезно изменена интеграция с Oauth2. Не забудьте сделать бэкап и будьте готовы поставить предыдущую.

Миграция на Spring Boot 3 (версия 6.6.3748+)

С версии 6.6.3748 выполнен переход на Spring Boot 3 и Java 21. Перед обновлением проверьте:

  • PATH: Должен указывать на /opt/java/openjdk/bin вместо /usr/local/openjdk-11/bin
  • JWTSECRET: Минимум 64 символа (ключ HS512, 512 бит) — с коротким ключом вход упадёт с WeakKeyException

Подробнее см. Версия 6.6.3748

Миграция на AWS SDK v2 (версия 6.6.4154+)

В версии 6.6.4154 внутренний клиент для работы с файловым хранилищем заменён с MinioClient SDK на AWS SDK v2 S3Client.

Подробнее см. Версия 6.6.4154

Ограничение на размер административной команды (версия 6.6.4630+)

С версии 6.6.4630 введено ограничение на количество учётных записей в административной команде (флаг full_access в БД).

Почему: все участники такой команды обладали всеми полномочиями в системе вне зависимости от настроек прав. Чтобы избежать ошибок, мы:

  • разрешили иметь максимум 2 учётные записи в административной команде;
  • запретили добавлять новых участников в неё.

Что делать, если в административной команде уже больше 2 участников:

  1. Создайте новую команду через админку.
  2. Добавьте в неё новую учётную запись или перенесите туда учётку администратора.
  3. В БД у текущей административной команды снимите флаг full_access.
  4. В БД у новой команды поставьте флаг full_access.

Это может потребовать дополнительной лицензии, но мы всегда выдаём +1 место именно для этих целей.

Лента релизов

Новые версии сверху. Каждая запись раскрывается — внутри разбор изменений из описания релиза; полный текст со схемами обновления и командами — по ссылке в записи.

Загружаем ленту релизов…

Политика по работе с известными уязвимостями

Мы отдаем высокий приоритет устранению известных уязвимостей и на наличии технической возможности устраняем такие неизвестности в первую очередь.