Odoo 20 расширяет офлайн-режим, чтобы пользователи могли создавать, редактировать, архивировать, разархивировать и удалять записи без активного подключения. Ранее выполненные поиски также можно запускать офлайн. После восстановления связи очереди синхронизации обрабатывают изменения, а офлайн-интерфейс и инструменты управления позволяют отслеживать процесс. (Odoo 20 Release Notes; Odoo Goes Offline) Это переводит офлайн-доступ из режима просмотра на случай сбоя в рабочий режим, который может изменять бизнес-данные. Организациям, оценивающим Odoo 20, следует проверять, как эти изменения ведут себя при синхронизации, а не только доступность записей во время сбоя.
Odoo Nightly указывает Odoo 20 как стабильный, рекомендуемый выпуск Community Edition, с датой September 2026 и поддержкой до Odoo 23. (nightly.odoo.com) Эта запись важна для планирования Community Edition, но она не подтверждает одинаковое покрытие офлайн-функций для всех платформ, среды Enterprise или настроенной базы данных. Покрытие следует проверять для целевого развертывания.
Что изменилось по сравнению с Odoo 19
Офлайн-режим Odoo 19 позволяет пользователям просматривать записи, открытые до потери соединения, но не изменять их в автономном режиме. Odoo 20 добавляет создание, редактирование, архивирование, разархивирование и удаление записей. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Это функциональное расширение, а не новое название для прежнего кэша. В Odoo 19 пользователи могут подготовиться к отключению, открыв нужные записи, но работа, изменяющая эти записи, должна ждать восстановления связи. Odoo 20 поддерживает как новые записи, так и изменения существующих в автономном режиме. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
При оценке версий следует различать доступ к кэшированной информации и возможность завершать и ставить в очередь операции с записями. Для процесса, которому нужны только справочные данные, требования отличаются от процесса с вводом данных, изменением статуса или удалением. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Подтверждённые офлайн-операции
Подтверждённые действия Odoo 20 охватывают пять этапов жизненного цикла записи: создание, редактирование, архивирование, разархивирование и удаление. Ранее выполненные поиски также доступны офлайн. (Odoo 20 Release Notes) Приёмочное тестирование должно включать как минимум один сценарий для каждого действия и подтверждать, что после повторного подключения и синхронизации отображается ожидаемое состояние записи.
Сессия Odoo's Experience описывает отдельный офлайн-интерфейс, очереди синхронизации и инструменты для мониторинга и управления синхронизацией. (Odoo Goes Offline) Эти функции следует включить в обучение пользователей и рабочие процедуры. Пользователи должны знать, где отображаются элементы очереди, как определить неразрешённый элемент и кто его проверяет. Предоставленный материал подтверждает наличие инструментов управления, но не определяет их полный рабочий процесс или административные права.
Кэширование и покрытие поиска требуют проверки
Документация Odoo 19 описывает офлайн-доступ через записи, открытые до потери связи. Odoo 20 отдельно подтверждает, что ранее выполненные поиски можно запускать офлайн. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Предоставленные источники не уточняют, сколько связанных данных сохраняется, как долго они доступны, применяются ли ограничения по объёму хранилища и доступно ли каждое поле, связанное с кэшированной записью. Они также не устанавливают, возвращает ли повторный офлайн-поиск исходный набор результатов или только данные, уже сохранённые на устройстве.
Перед утверждением офлайн-процесса командам следует определить поисковые запросы и типы записей, необходимые каждой роли. Тестирование должно начинаться онлайн с выполнения нужных поисков и открытия требуемых записей. Затем тестировщики могут отключиться и повторить запланированные задачи, включая использование вложений, связанных записей и обязательных полей. Это точки проверки, а не подтверждённые ограничения, поскольку в предоставленной информации о выпуске их поведение не описано. (Примечания к выпуску Odoo 20)
Обработка конфликтов требует тестирования
Очереди синхронизации и инструменты управления подтверждены, но предоставленные источники не объясняют, как Odoo 20 разрешает конкурирующие изменения одной и той же записи, сбои проверки после повторного подключения или зависимости между операциями в очереди. (Odoo уходит в офлайн) Наличие очереди само по себе не определяет политику разрешения конфликтов. Её поведение следует продемонстрировать в целевой сборке и конфигурации Odoo.
Тест на конфликт может включать ситуацию, когда один пользователь изменяет запись в офлайне, а другой меняет ту же запись онлайн. После повторного подключения команде следует проверить итоговые значения, состояние очереди и уведомление пользователю. Отдельные тесты должны охватывать офлайн-редактирование записи, которую где-то ещё архивировали или удалили, а также новую запись, которая не проходит серверное правило. В тестировании следует зафиксировать, имеет ли обновление приоритет, происходит ли слияние или требуется ручное вмешательство. (Odoo уходит в офлайн)
Контроль доступа и деструктивные действия
Поскольку Odoo 20 включает офлайн-архивирование, разархивирование и удаление, оценка должна выходить за рамки обычного ввода данных. (Примечания к выпуску Odoo 20) Организациям следует проверить, применяются ли права доступа, правила записей и требования утверждения, когда офлайн-действие выполняется, во время синхронизации или на обоих этапах. В примечаниях к выпуску подтверждены доступные действия, но не объясняется, как работает каждый механизм безопасности без соединения.
Тестирование следует проводить с представителями реальных ролей пользователей, а не только с учётной записью администратора. Каждая роль должна попытаться выполнить разрешённые и запрещённые действия как при подключении, так и без него. Затем тестировщикам следует проверить, остаются ли видимыми изменения в очереди, насколько понятны сообщения об отказе и достигают ли архивированные, восстановленные или удалённые записи нужного итогового состояния. Процессы, в которых удаление имеет серьёзные последствия, должны иметь документированную офлайн-процедуру до внедрения. (Примечания к выпуску Odoo 20; Odoo уходит в офлайн)
Пользовательские модули требуют целевого тестирования
Подтверждённая функция охватывает офлайн-операции с записями и средства синхронизации в Odoo 20, но в предоставленных источниках не сказано, что каждый пользовательский модуль, модуль стороннего разработчика, автоматическое действие или внешняя интеграция совместимы с работой в офлайне. (Примечания к выпуску Odoo 20; Odoo уходит в офлайн) Поэтому кастомизированные внедрения должны оценивать поддержку по каждому модулю отдельно, а не исходить из того, что офлайн-режим одинаково применяется ко всей базе данных.
Тестирование должно охватывать пользовательские поля, поведение onchange, обязательные значения, вычисляемые значения и серверные проверки, используемые в рабочих процессах организации. Интеграции, которые обычно реагируют на создание или редактирование записи, также следует наблюдать после синхронизации изменений из очереди. Цель не в том, чтобы предполагать сбой, а в том, чтобы определить, работает ли каждый элемент в офлайне, ждёт ли он повторного подключения, создаёт ли отклонённый элемент очереди или требует иного процесса. (Примечания к выпуску Odoo 20; Odoo уходит в офлайн)
Вопросы, которые нужно решить до развёртывания
Odoo 20 предоставляет более широкий подтверждённый набор офлайн-возможностей, чем Odoo 19, с выделенным интерфейсом и инструментами синхронизации для задач в очереди. (Документация Odoo 19.0: Общий офлайн-режим; Примечания к выпуску Odoo 20; Odoo уходит в офлайн) Прежде чем полагаться на эти возможности, организации следует проверить, какие приложения и типы записей охвачены, что пользователи должны открыть или найти до отключения, как отображаются конфликты и кто отслеживает сбои или задержки синхронизации.
Решение о развёртывании также должно фиксировать поддерживаемые устройства и среды размещения, поведение хранения и сроков хранения, результаты контроля доступа, итоги работы пользовательских модулей и процедуры для удаления или других значимых изменений. Предоставленные материалы к выпуску не отвечают на эти вопросы внедрения, но именно они определяют, подходят ли подтверждённые функции для конкретного офлайн-сценария. (Примечания к выпуску Odoo 20; Odoo уходит в офлайн)
При планировании Community Edition список стабильной и рекомендуемой версии Odoo Nightly указывает заявленный статус версии, с поддержкой до Odoo 23. (nightly.odoo.com) Операционное одобрение по-прежнему должно зависеть от тестирования точной сборки, модулей, разрешений и рабочих процессов, которые пользователи будут использовать в офлайне. Подтверждённое изменение состоит в том, что Odoo 20 выходит за рамки доступа только для чтения к ранее открытым записям в Odoo 19, позволяя создавать и изменять данные в офлайне через очередь. Тестирование должно установить, как эта возможность работает в конфигурации организации. (Документация Odoo 19.0: общий режим офлайн; Примечания к выпуску Odoo 20; Odoo уходит в офлайн)