В основной документации Odoo указано, что устаревшая служба RPC базы данных удаляется в Odoo 20. Более широкие XML-RPC и JSON-RPC API считаются устаревшими с версии 19.0, но Odoo 20 не удаляет все устаревшие службы. В документации Odoo указано, что общая и объектная службы останутся доступными до Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Поэтому командам интеграции нужно определить, какая служба используется каждым внешним подключением, а не рассматривать поддержку устаревшего RPC как одну функцию с одной датой удаления.
На странице мероприятия Odoo для Америки было указано, что Odoo 20 выйдет во время события в Сан-Франциско 2 и 3 сентября 2026 года. (Oxp26 Americas Introduction) Планирование обновления уже может учитывать документированное удаление службы базы данных, но производственные решения следует сверять с финальной документацией по выпуску Odoo 20.
Удаление относится к конкретной службе
Odoo указывает `/xmlrpc`, `/xmlrpc/2` и `/jsonrpc` как устаревшие конечные точки, deprecated с версии 19.0. Внутри этих API служба базы данных удаляется в Odoo 20, а общая и объектная службы запланированы к сохранению до Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Интеграция, использующая сохранённую службу, может продолжить работу после обновления до Odoo 20, но одна лишь конечная точка не подтверждает совместимость.
Система может использовать разные службы через устаревший RPC-интерфейс. Поэтому при анализе интеграции следует фиксировать и конечную точку, и вызываемую службу. Описание приложения только как XML-RPC или JSON-RPC интеграции не показывает, зависит ли оно от операции, удалённой в Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Сохранение доступности общей и объектной служб носит временный характер. Odoo планирует удалить обе в Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Команды могут разделить срочную работу по вызовам службы базы данных и миграцию сохранённых служб, но для обоих направлений нужен план.
JSON-2 меняет контракт запроса
Odoo описывает JSON-2 как заменяющий API. Формат его конечной точки: `/json/2/<model>/<method>`, где модель и метод включены в URL. (Odoo master Docs: Reference External API) Следовательно, миграция означает не просто замену базового пути в существующем RPC-клиенте. Каждую операцию нужно сопоставить с подходящим маршрутом модели и метода.
JSON-2 требует именованных аргументов в теле JSON-запроса вместо позиционных RPC-аргументов. (Odoo master Docs: Reference External API) Существующие обёртки, промежуточное ПО и сгенерированные клиенты могут исходить из того, что порядок аргументов определяет смысл. Эти компоненты требуют отдельной проверки. Перенаправление устаревшего запроса на новую конечную точку не сработает, если клиент по-прежнему формирует позиционные параметры.
Для каждой перенесённой операции команды должны документировать целевую модель, метод и именованные аргументы, требуемые JSON-2. (Odoo master Docs: Reference External API) Затем запросы следует протестировать в соответствующей среде Odoo 20, особенно если общая библиотека интеграции формирует вызовы для нескольких приложений. Сравнение статических полезных нагрузок не может подтвердить, как сервер или клиент обрабатывает весь запрос.
Аутентификация также должна измениться
JSON-2 использует аутентификацию по API-ключу bearer. (Odoo master Docs: Reference External API)Работы по миграции должны охватывать создание ключей, безопасное хранение, обработку заголовка авторизации и замену ключей. Прокси, шлюзы и клиентские библиотеки следует проверить, чтобы убедиться, что они сохраняют заголовок при пересылке запросов. Также нужно пересмотреть ведение журналов, мониторинг и обработку ошибок, чтобы учетные данные не были раскрыты.
Документация определяет метод аутентификации, но каждая организация должна сама определить, как API-ключи вписываются в ее контроль учетных данных. (Odoo master Docs: Reference External API) Это включает распределение ответственности за ключи, контроль мест, где их можно использовать, и определение того, как будут обновляться затронутые интеграции при замене ключа.
Поля binary имеют отдельное изменение совместимости
Журнал изменений ORM Odoo фиксирует еще одно изменение RPC в Odoo 20: в представление полей binary добавлен `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) Это отдельно от удаления database-service, потому что меняется возвращаемые данные, а не доступность сервиса. Приложения, которые читают, преобразуют или проверяют ответы, содержащие поля binary, следует включить в тестирование совместимости.
Журнал изменений подтверждает, что член `filename` добавлен, но его практический эффект зависит от клиента. (Odoo master Docs: Orm Changelog) Тесты должны проверить, принимают ли строгие схемы, сериализаторы, сравнение ответов и последующие преобразования дополнительный член. Клиентам, которые игнорируют неизвестные поля, может не потребоваться настройка, но это поведение следует проверить, а не предполагать.
Как определить объем аудита интеграций
Начните с выявления подключений, которые используют `/xmlrpc`, `/xmlrpc/2` или `/jsonrpc`, которые Odoo помечает как устаревшие конечные точки. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Инвентаризация должна охватывать приложения собственной разработки, промежуточное ПО, запланированные процессы и сторонние коннекторы, для которых доступна конфигурация или исходный код. Назначьте владельца каждому подключению, чтобы можно было проверить его назначение и статус.
Затем классифицируйте каждое подключение по устаревшему сервису. Использование database-service требует исправления для Odoo 20, тогда как использование common и object service по-прежнему задокументировано как доступное до Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Это поддерживает поэтапный план: сначала устраните несовместимость с Odoo 20, затем назначьте даты миграции для остальных устаревших вызовов.
Для интеграций, переходящих на JSON-2, зафиксируйте маршрут `/json/2/<model>/<method>`, именованные аргументы запроса и аутентификацию с помощью bearer API-ключа, требуемую заменяющим интерфейсом. (Odoo master Docs: Reference External API) Тестовые случаи должны охватывать успешные запросы, отклоненную аутентификацию, недопустимые именованные аргументы и обработку возвращаемых данных приложением. Добавляйте случаи с binary-полями там, где они встречаются.
Подтвердите итоговое поведение Odoo 20
Сведения об удалении взяты из мастер-документации разработчика Odoo, а объявленное время выпуска взято со страницы мероприятия, где сказано, что Odoo 20 будет выпущен во время мероприятия Americas в сентябре 2026 года. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Перед развертыванием командам следует еще раз проверить документацию для выпущенной версии Odoo 20 и точную редакцию и сборку, которые они собираются использовать.
Использование устаревшей RPC-конечной точки само по себе не доказывает, что интеграция перестанет работать в Odoo 20, поскольку common и object service по-прежнему задокументированы как доступные до Odoo 22. И наоборот, успешная работа в более ранней версии не подтверждает совместимость для вызова database-service после его удаления. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Контрольный список для решения об обновлении
Перед утверждением обновления до Odoo 20 лица, принимающие решения, должны запросить реестр интеграций, в котором указаны каждая устаревшая конечная точка, вызываемый сервис, его владелец и запланированное устранение. Для зависимостей от database-service должна быть подготовлена и протестирована замена. Для интеграций, остающихся на common или object service, должна быть отдельная дата миграции, отражающая их документированное удаление в Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Проверка должна подтвердить, что реализации JSON-2 помещают модель и метод в URL, используют именованные аргументы JSON и выполняют аутентификацию с помощью API-ключа bearer. Если присутствуют бинарные поля, тестирование должно учитывать добавление `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Эти проверки позволяют отличить немедленное удаление службы базы данных в Odoo 20 от более позднего вывода из эксплуатации остальных устаревших служб.