Файл конфигурации Odoo (odoo.conf)¶

Где лежит¶

В корне каталога odpm-проекта файл {platform_name}.conf. Для стандартной платформы это обычно odoo.conf. Имя зависит от поля platform_name в odpm.json.

Зачем файл на диске, если Odoo в контейнере¶

Разработчик или администратор редактирует конфигурацию привычным способом — текстовым файлом в каталоге проекта. odpm не требует заходить в контейнер, чтобы поменять, например, proxy_mode или уровень журналирования.

При каждой подготовке окружения odpm:

Читает ваш файл с диска.
Накладывает переопределения из odoo_conf в odpm.json (если заданы) — manifest сильнее диска.
Подставляет параметры подключения к базе из служебной конфигурации.
Пересчитывает пути к дополнениям (addons_path) и каталог данных (data_dir) так, как их видит процесс внутри контейнера (они отличаются от путей на хосте).
Записывает результат в служебный JSON (.odpm/runtime/config.json).
При старте контейнера точка входа создаёт конфигурационный файл внутри контейнера и передаёт Odoo параметр -c с этим путём.

То есть файл в каталоге проекта — ваш интерфейс настройки; в контейнер попадает согласованная версия с правильными путями.

Что можно править вручную¶

Параметры из документации Odoo: proxy_mode, dbfilter, log_level, число воркеров и т.д. Дополнительные секции INI для модулей ([redis_server], [s3_server], …) можно задать в manifest odoo_conf рядом с options — см. поля odpm.json.

На сервере, доступном из интернета, обычно настраивают proxy_mode и dbfilter вместе с обратным прокси (nginx). Для CI/preview те же ключи можно задать в odoo_conf в odpm.json.

Приоритет источников¶

odpm-managed (addons_path, data_dir)  ← всегда сильнее всего
    ↑
manifest odoo_conf.options            ← перекрывает диск
    ↑
odoo.conf на диске                    ← локальные значения по умолчанию

Что odpm перезапишет при подготовке¶

addons_path — полный список путей к дополнениям внутри контейнера;
data_dir — каталог данных Odoo внутри контейнера;
db_host — по умолчанию синхронизируется с физическим именем postgres-сервиса из .env (POSTGRES_SERVICE_NAME или {prefix}db при ODPM_COMPOSE_PREFIX);
маркеры базы в шаблоне — реальные значения из runtime;
admin_passwd — в контейнере из db_manager_password (не из manifest).

Двухслойная frozen policy (ADR-022)¶

В manifest odoo_conf.options действует сценарий-зависимая политика:

Слой	Ключи	Где запрещены
Global	`addons_path`, `data_dir`, `admin_passwd`, `http_port`	во всех сценариях
Scenario	`db_host`, `db_port`, `db_user`, `db_password`	в `developer` и `server`; разрешены в effective slice `ci`

odpm manifest validate / load_manifest при нарушении показывают полный список ключей для текущего сценария. Отдельного блока и флага external нет: наличие любого db_* в effective ci — derived-сигнал для runtime.

Если в scenarios.ci.odoo_conf.options заданы db_* (внешняя БД), шаг template.odoo_conf не regen из‑за db_host_mismatch с compose-сервисом, и plan не показывает ложный drift db_host_mismatch. Compose-сервис db odpm не удаляет автоматически. Host ensure_app_role / odpm database по-прежнему таргетируют compose postgres. См. ADR-022.

Если db_host на диске не совпадает с ожидаемым именем postgres-сервиса и CI override не активен, шаг template.odoo_conf пересоздаёт конфиг; в odpm plan появится drift db_host_mismatch. См. состояние PostgreSQL.

Когда файл пересоздаётся целиком¶

Если файл отсутствует, повреждён или в нём не заполнены обязательные параметры базы — odpm создаст шаблон заново.

После правок, влияющих на пути или состав дополнений: odpm --skip-start и перезапуск контейнеров.

Сценарий сборки образа (`ci`)¶

Та же логика конфигурации встраивается в образ при odpm --build-image.