Введение
Если при сохранении формы в Odoo вы видели поле, подсвеченное красным, — это и есть механизм обязательного поля. Это базовый способ гарантировать, что ключевые данные появятся в карточках, а процессы не сломаются из‑за пустых значений.
Независимо от того, настраиваете ли вы систему для отдела продаж, создаёте свою модель или пишете модуль на Python, понимание атрибута required помогает строить устойчивые и предсказуемые бизнес‑процессы в Odoo.
В этом обзоре мы разберём, как атрибут required действует внутри фреймворка, как его задать через Studio или код, в каких ситуациях его стоит применять и какие ошибки нужно избегать.
Что значит «обязательное поле» в Odoo
В Odoo required — это свойство поля, которое запрещает сохранить запись, если значение пустое. Оно применимо к почти всем типам полей: строки, числа, выпадающие списки, связи many2one, даты и т.д.
Это часть основной модели данных Odoo и один из самых часто используемых инструментов при кастомизации. Пометив поле как обязательное, вы сразу улучшаете качество данных в системе.
Как это выглядит в интерфейсе
В пользовательском интерфейсе Odoo обязательные поля визуально отличаются от необязательных. В режиме редактирования у таких полей есть индикатор; при попытке сохранить форму без заполненного обязательного поля система подсветит его и выведет предупреждение.
То есть пользователь получает мгновенную обратную связь, что снижает вероятность отправки неполной карточки и ускоряет исправление ошибок на месте.
Статическое и динамическое требование
Есть два подхода: статическое required — поле всегда обязательно, и динамическое — поле становится обязательным только при выполнении определённого условия, например, по значению другого поля в той же записи.
Оба подхода активно используются в реальных проектах; выбор зависит от бизнес‑логики и удобства пользователей.
Принцип работы механизма
Технические детали работы атрибута required
Где проверяется требование
Важно помнить: проверка required выполняется на уровне приложения, а не прямо в базе данных. Это значит, что ORM Odoo контролирует заполнение поля при создании или изменении записи до того, как данные попадут в PostgreSQL.
При установке required=True Odoo по умолчанию не добавляет в колонку БД ограничение NOT NULL. Проверка идёт в Python‑слое ORM, а не на уровне схемы БД.
Из этого следует вывод: если вставлять строки напрямую в базу, минуя ORM, вы обойдёте валидацию. Поэтому всегда работайте с полями через ORM или официальный API, чтобы сохранять целостность данных.
Что происходит при нарушении ограничения
Если пользователь пытается сохранить форму с пустым обязательным полем, система отрабатывает две вещи:
- поле подсвечивается в интерфейсе и выводится сообщение о валидации;
- операция сохранения блокируется до тех пор, пока поле не заполнено.
При программной записи (через API или серверные действия) Odoo выбросит ValidationError с указанием, какое поле отсутствует.
Динамическая обязательность через домены/выражения
В интерфейсной части required можно сделать условным с помощью выражений в представлениях. В Odoo 16 и ранее это делалось через атрибут attrs в XML представлениях:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />В Odoo 17 и новее синтаксис упростили, позволив записывать выражение прямо в атрибут required:
<field name="x_delivery_date" required="order_type == 'delivery'" />Важно: такие правила живут в слое представления, а не в модели. required=True на уровне модели жестко контролирует обязательность где бы ни создавалась запись, а выражение в view действует только при использовании конкретного интерфейса.
Взаимодействие с ORM и API
Когда ORM вызывает create() или write(), он проверяет все поля, у которых в модели стоит required=True. Если такое поле отсутствует или равно False, будет поднята ValidationError и запись не сохранится.
То же правило действует при создании записей через XML‑RPC и прочие API: модельные обязательные поля нужно передавать в данных, иначе вызов завершится ошибкой.
Бизнес-сценарии применения
Где это реально помогает — примеры из практики
1) CRM: обязательный сегмент клиента для лидов
Чтобы потом корректно анализировать лиды по сегментам, отдел продаж может требовать указать сегмент ещё на этапе создания лида. Без такого требования менеджеры порой пропускают этот шаг, и аналитика теряет смысл.
Добавление обязательного поля «Сегмент клиента» на форме лида гарантирует, что данные собираются сразу при вводе: нет сегмента — запись не сохраняется.
2) Продажи: обязательный адрес доставки в заказе
Для компаний, отправляющих товар, адрес доставки критичен. В некоторых конфигурациях Odoo он по умолчанию необязателен, и заказ можно подтвердить без него.
Сделав адрес доставки обязательным на форме заказа, вы исключаете подтверждение заказа без логистической информации и сокращаете ошибки в отгрузке.
3) Склад: обязательный номер партии/серии при приёме
В отраслях с регуляциями (пищевая, фарма, электроника) отслеживание партий обязательно. Odoo поддерживает это через трекинг товара, что фактически делает номер партии обязательным при движениях запасов.
Для дополнительных полей при приёме, например ссылки на контроль качества, установка обязательности гарантирует, что склад всегда запишет нужную информацию при входящем поступлении.
4) Бухгалтерия: обязательный центр затрат на счёте поставщика
Финансистам часто нужно, чтобы каждая затратная операция была отнесена к центру затрат. Без обязательного поля менеджеры могут оставлять его пустым, и отчётность будет неполной.
Добавление required поля типа many2one на форму счета поставщика не даст провести документ без привязки к центру — простая настройка, большой эффект для заполненности данных.
5) HR: тип контракта обязателен до завершения оформления
При массовом приёме сотрудников HR‑специалисты не должны случайно сохранять неполные карточки. Обязательное поле «Тип контракта» на форме сотрудника защищает процесс онбординга и предотвращает незавершённые записи.
Как создать или настроить обязательное поле
Способы задать поле как обязательное
Два основных пути: Odoo Studio для no‑code и код на Python для полного контроля. Какой выбрать — зависит от задач и уровня доступа к разработке.
Работа через Odoo Studio
Studio — встроенный инструмент для быстрой настройки без программирования. Выбрав поле на форме, вы увидите переключатель «Required» в панели свойств, который делает поле обязательным и сохраняет это в модели.
Это самый быстрый способ для простых случаев и не требует навыков программирования, но он подходит преимущественно для статической обязательности.
Технический подход: поля в Python
В модуле можно объявить поле required, указав required=True в определении field. Это стандартный приём в разработке на Odoo и даёт модельную обязательность:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Public Sector'),
],
string='Customer Segment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Cost Center',
required=True,
)Такой подход обеспечивает жёсткое требование на уровне модели: оно будет работать независимо от того, через какой интерфейс или API создаётся запись.
Динамическая обязательность в XML представлениях
Если обязательность должна действовать в отдельных ситуациях, лучше задавать её на уровне представления. В Odoo 16 пример выглядел бы так:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />В Odoo 17 синтаксис стал компактнее:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Помните: это ограничение интерфейсное и применимо только в тех видах, где оно задано — оно слабее, чем модельное required=True.
Создание обязательных полей через API
При программном создании полей через XML‑RPC можно сразу установить required в записи ir.model.fields. Это удобно для автоматизированных развертываний и сценариев, где инфраструктура создаёт поля сама.
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Так вы создаёте поле и фиксируете требование одним запросом — удобно для CI/CD и скриптов установки модулей.
Рекомендации по использованию
Полезные приёмы и правила, которые сэкономят время
1) Делайте поле обязательным только если это действительно нужно
Чрезмерная обязательность приводит к тому, что пользователи начинают вводить заглушки и обходные пути, чтобы завершить работу. Это портит данные и создаёт дополнительные проблемы при аналитике.
Перед тем как пометить поле required, спросите: доступна ли эта информация всегда при создании? Если нет, перенесите проверку на более поздний этап или примените динамическую обязательность.
2) Валидируйте по этапам, а не сразу всё и всегда
Для многошаговых процессов разумно проверять поля при переходе записи на ключевые стадии — например, при закрытии сделки или при подтверждении заказа. Это можно реализовать через контролирующие ограничения в Python или автоматизации при изменении стадии.
Такой подход гибче и лучше воспринимается пользователями, чем режим «всё обязательно сразу».
3) Используйте значения по умолчанию там, где это уместно
Если поле обычно принимает одно и то же значение, задайте default. Это снижает трение для пользователей и при этом сохраняет требование заполненности.
4) Для критичных данных предпочитайте модельный уровень
Для ключевой информации — бухгалтерских реквизитов, идентификаторов по регуляции и т. п. — лучше ставить required=True в Python. Ограничения на уровне представления можно обойти через API или другой вид, тогда данные потеряют гарантии целостности.
5) Сообщайте пользователям об изменениях заранее
Если вы добавляете обязательные поля в уже работающую систему, предупредите команду: незаполненные существующие записи могут начать вызывать ошибки при следующем редактировании.
6) Тестируйте с пустыми и частичными данными
Перед развёртыванием новой обязательности прогоните сценарии с пустыми и частичными значениями через интерфейс, API и автоматизации. Это базовая практика при изменениях модели данных.
Типичные ошибки и ловушки
Типичные проблемы, с которыми сталкиваются даже опытные внедренцы
Проблема 1: добавление required в модели с существующими записями
Если вы включаете required=True в модели, где уже есть тысячи записей без значения для этого поля, при следующем редактировании таких записей пользователи не смогут сохранить изменения, пока не заполнит поле.
Перед развертыванием сделайте аудит данных и, при необходимости, миграцию, чтобы заполнить поле заранее.
Проблема 2: путаница между уровнем представления и моделью
Установка обязательности в представлении (через Studio или XML) не защищает записи, созданные через API или другой вид. Если нужна жёсткая гарантия, ставьте required на уровне модели в Python.
Это частая причина проблем с качеством данных в продакшене.
Проблема 3: автоматизации и планировщики начинают падать
Если автоматический скрипт создаёт записи, а вы добавили новое обязательное поле, этот код начнёт ошибиться, если не передавать новое значение. Ошибки могут быть непонятны и появляться неожиданно.
После изменений проверьте все автоматические сценарии и задания, которые создают записи в этой модели.
Проблема 4: импорт данных без обязательных полей
При импорте CSV или через инструмент импорта отсутствие обязательных полей приведёт к отказу загрузки. Это корректное поведение, но часто неожиданное для тех, кто привык импортировать неполные таблицы.
В импортные шаблоны всегда включайте обязательные поля и документируйте требования для пользователей.
Проблема 5: попытки заменить валидацию сложной логикой required
Атрибут required проверяет только ненулевое значение поля. Для более тонкой логики — например, «дата должна быть в будущем» или «два поля должны согласовываться» — используйте @api.constrains в Python или другие серверные проверки.
Опора только на required для сложных правил ведёт к негибким и трудноподдерживаемым решениям.
Итоги
Подводя итог: required — простой, но мощный инструмент. При правильном использовании он существенно повышает качество данных и надёжность процессов. При неправильном — создаёт трения и порождает обходные решения у пользователей.
Ключевое — чётко понимать разницу между модельной и интерфейсной обязательностью, осознанно выбирать, какие поля действительно нужно защищать, и планировать влияние на автоматизации и интеграции.
Понимание механизма required — это то, что отличает аккуратно настроенный Odoo от системы, которая начнёт давать проблемы спустя несколько месяцев после внедрения. Потратьте время на продуманный дизайн данных — это окупится.
Нужна помощь с внедрением Odoo?
Компания Dasolo специализируется на внедрениях, настройках и оптимизации Odoo для разных отделов и уровней сложности. Мы помогаем проектировать надёжные модели данных, выстраивать правила валидации и разрабатывать кастомные модули, сочетая функциональное видение и технические навыки.
Если у вас остались вопросы по обязательным полям или другим аспектам настройки Odoo, мы готовы проконсультировать и помочь с реализацией. Свяжитесь с нами и расскажите, какой процесс вы хотите настроить.