Введение
Любая форма в Odoo состоит из набора полей. Часть из них пользователю приходится заполнять вручную, но многие можно заранее предзаполнить, чтобы форма уже при открытии была полезной. Механизм значений по умолчанию прост в своей сути, но при настройке он имеет несколько уровней и нюансов — от интерфейсных настроек до места хранения в базе данных — которые важно понимать, чтобы не получить неожиданные результаты при внедрении.
Независимо от того, настраиваете ли вы форму через визуальный редактор Odoo Studio или пишете код в модуле, понимание логики дефолтов экономит время и помогает избежать тихих ошибок конфигурации, которые потом тяжело отловить в рабочем процессе.
Этот материал объясняет, что такое дефолты в Odoo, как они вычисляются в ORM, когда выбирать статические или динамические значения, и как задавать их через Studio и в Python-коде.
Что такое значение по умолчанию в Odoo
В терминах Odoo значение по умолчанию — это то, что подставляется в поле при создании новой записи до того, как пользователь начнёт ввод. Это не правило валидации и не запрет на изменение — просто стартовая настройка, которая делает форму удобнее и меньше подверженной ошибкам ввода.
Параметр default доступен для большинства типов полей в Odoo: Char, Integer, Float, Boolean, Date, Many2one, Selection и других. В качестве дефолта можно указывать простое значение, лямбду на Python или ссылку на метод — выбор зависит от задачи, которую вы решаете.
В Odoo Studio задавать дефолты очень просто: в панели свойств поля есть поле «Значение по умолчанию», где можно вписать фиксированное значение. Это самый доступный путь для бизнес-пользователей улучшить консистентность данных без привлечения разработчиков.
На уровне базы данных дефолты не пишутся прямо в столбцы таблиц. Они хранятся либо в определении модели в Python, либо в записях модели ir.default в базе, если дефолт задан через интерфейс. При создании новой записи Odoo читает эти источники и заполняет форму заранее.
Как работает механизм значений по умолчанию
Когда пользователь открывает форму для добавления записи, фреймворк вызывает метод default_get() модели. Он собирает дефолтные значения и возвращает словарь «имя_поля → значение», которым затем заполняются поля формы до взаимодействия с пользователем.
В Odoo принято выделять четыре основных вида дефолтов — каждый покрывает свою ситуацию использования.
Статические дефолты
Это фиксированные значения: прописанные в определении поля или выставленные через Studio. Например, булево поле по умолчанию True или Selection, у которого выбран пункт 'draft'. Такие дефолты просты и охватывают большинство повседневных сценариев в моделях данных.
Динамические дефолты (лямбда или метод)
Значение, вычисляемое при создании записи с помощью функции или лямбды. Это позволяет опираться на текущую дату, авторизованного пользователя, контекст или любые доступные параметры в момент создания. Типичный пример — автоматически назначить ответственного как текущего пользователя или подставить сегодняшнюю дату в поле документа.
Ниже — пример, как это обычно выглядит в определении модели на Python, с типичными конструкциями для статических и динамических дефолтов:
from odoo import fields, models
class CrmLead(models.Model):
_inherit = 'crm.lead'
# Пример статического дефолта
x_priority_level = fields.Selection(
[('low', 'Низкий'), ('medium', 'Средний'), ('high', 'Высокий')],
string='Уровень приоритета',
default='medium',
)
# Дефолт — текущий пользователь
x_assigned_by = fields.Many2one(
'res.users',
string='Назначил',
default=lambda self: self.env.user,
)
# Дефолт — сегодняшняя дата
x_expected_date = fields.Date(
string='Ожидаемая дата закрытия',
default=lambda self: fields.Date.today(),
)
Дефолты, передаваемые через контекст
При создании записи из связанного сущности часто используется соглашение default_field_name в контексте действия. Например, создавая задачу из карточки проекта, Odoo автоматически передаёт идентификатор проекта в контекст, и поле project заполняется. Это удобный механизм для навигационных сценариев и его можно настраивать как на стороне кода, так и в конфигурации действий.
Пользовательские дефолты через ir.default
Odoo поддерживает персональные дефолты в модели ir.default. Администратор может задать дефолт для конкретного пользователя — тогда при создании записи этот пользователь увидит свой персональный стартовый выбор, который перекрывает дефолт модели. Это полезно, когда у членов команды разные предпочтения рабочего процесса.
Порядок приоритета дефолтов
Если для одного поля задано несколько источников дефолта, Odoo применяет их в порядке: сначала пользовательский ir.default, затем company-scoped ir.default, потом дефолт, прописанный в модели Python. Контекстные дефолты, переданные в момент открытия формы, тоже имеют приоритет над модельными. Знание этого порядка важно при отладке, почему поле показывает не то значение, которое вы ожидали.
Бизнес-сценарии применения
Дефолты присутствуют почти в каждом модуле Odoo. Приведём пять практических примеров из реальных бизнес-процессов.
CRM: дефолтный продавец для новых лидов
Когда продавец создаёт новый лид, поле «Ответственный» по умолчанию ставится в текущее пользователя. Это предотвращает появление незакреплённых лидов и облегчает контроль. На уровне модели это обычно реализовано как default=lambda self: self.env.user — простая деталь, заметно повышающая принятие CRM сотрудниками.
Продажи: дефолтные условия оплаты в заказах
При создании заказа системе подставляет прайс-лист и условия оплаты из карточки клиента. Если для клиента указано Net 30, это значение автоматически появится в новом заказе. Такой подход сокращает ошибки и гарантирует единообразие в применении коммерческих условий, даже если заказы создают разные сотрудники.
Склад: дефолтные локации при перемещениях
При формировании внутреннего перемещения или оприходования источником и местом назначения становятся настройки склада. Сотрудники, работающие в одной зоне, увидят нужную локацию уже выбранной, что экономит время и уменьшает риск ошибочного выбора в стрессовой обстановке.
Бухгалтерия: дефолтный журнал для проводок
При создании счета или расходной накладной Odoo подставляет подходящий журнал в зависимости от типа операции и настроек компании. Это делается динамически через конфигурацию компании, поэтому даже после изменения структуры журналов дефолт останется корректным без правки кода.
Проекты: дефолтный статус для новых задач
Новая задача внутри проекта стартует в первом статусе доски канбан этого проекта. При создании задачи из карточки проекта контекст также может заполнить проект и иногда исполнителя. Такой подход держит рабочий процесс организованным с момента создания задачи.
Создание и настройка значений по умолчанию
Есть три основных способа задать дефолты: без кода через Studio, программно в Python и через запись ir.default (в том числе в модульных данных). Каждый подходит под разные задачи и уровень контроля.
Через Odoo Studio (без кода)
Studio даёт визуальный интерфейс для выставления дефолтов на любом поле формы. Пошагово это делается так:
- Откройте Studio на нужной форме
- Выберите поле для настройки
- В панели свойств справа найдите поле «Значение по умолчанию»
- Укажите желаемое стартовое значение
- Сохраните изменения и выйдите из Studio
Studio сохраняет такую настройку как запись ir.default в базе и по умолчанию она действует глобально по компании, если не ограничена на уровне пользователя. Это удобно для статических дефолтов в Selection, Boolean, Char и Integer. Для Many2one Studio позволяет выбрать существующую запись из списка — простое и практичное решение без кода.
Важно помнить: изменение дефолта через Studio не перерабатывает уже созданные записи. Новое значение начнёт применяться только к записям, созданным после изменения.
Через Python в технической кастомизации
Если нужна полная гибкость — задавайте дефолты в определении поля на Python. Это даёт контроль над статикой, лямбдами и более сложными методами. Такой подход обязателен, когда дефолт зависит от runtime-данных: текущего пользователя, даты, параметров компании и т.д.
Ниже пример типичной реализации нескольких видов дефолтов в кастомном модуле:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
# Статический булев дефолт
x_requires_review = fields.Boolean(
string='Требует проверки',
default=False,
)
# Статический Selection дефолт
x_delivery_preference = fields.Selection(
[('standard', 'Обычная'), ('express', 'Экспресс')],
string='Предпочтение доставки',
default='standard',
)
# Дефолт из метода
def _default_note(self):
return self.env['ir.config_parameter'].sudo().get_param(
'sale.default_note', default=''
)
x_internal_note = fields.Text(
string='Внутренняя заметка',
default=_default_note,
)
Эта схема соответствует общепринятому стилю разработки в Odoo: методные дефолты удобны, когда логика выходит за рамки простой лямбды или требует доступа к конфигурации и параметрам системы.
Создание ir.default программно
Записи ir.default можно создавать или обновлять через XML-импорт в модуле или по API (XML-RPC). Это пригодится, если вы хотите включить преднастройки прямо при установке модуля: указать модель, поле, значение и опционально область применения по компании или пользователю.
Хотя такой путь встречается реже в рутинной разработке, он полезен при поставке готовых решений, где требуется установить набор дефолтов автоматически вместе с модулем.
Рекомендации по использованию значений по умолчанию в Odoo
Дефолты для обязательных полей
Если поле обязательно, по возможности задавайте разумный дефолт. Это снижает трение и предотвращает ошибки сохранения, когда пользователь случайно пропустил поле. Сочетание required=True и практичного дефолта — хорошая практика в проектировании модели данных.
Используйте лямбды для дат
Никогда не хардкодьте дату в качестве дефолта. Применяйте lambda self: fields.Date.today(), чтобы дефолт всегда соответствовал текущей дате при создании записи. Хардкод быстро устаревает и сразу приводит к неправильным значениям.
Держите логику дефолтов лёгкой
Дефолт-функции выполняются при инициализации формы, то есть при каждом открытии создания записи. Избегайте в них тяжёлых запросов, внешних вызовов или сложных вычислений. Если нужна более тяжёлая логика — перенесите её в onchange или в вычисляемое поле, чтобы не замедлять интерфейс создания записи.
Используйте контекст для навигации
При создании кастомных действий или кнопок, которые открывают форму, передавайте default_field_name через context вместо того, чтобы полагаться на статический дефолт модели. Это соответствует поведению нативных действий Odoo и делает ваши кастомизации предсказуемыми.
Тестируйте дефолты под разными пользователями
Динамические дефолты, зависящие от self.env.user или self.env.company, будут отличаться для разных аккаунтов. Обязательно проверяйте поведение под несколькими пользователями и, при необходимости, в мультикомпанийной среде. То, что корректно отображается у администратора, может вести себя иначе для обычного сотрудника.
Распространённые ошибки и подводные камни
Не используйте изменяемые объекты как дефолт
Классическая ошибка Python применима и в Odoo: не писать default=[] или default={} напрямую. Такие объекты будут общими для всех записей, что приводит к нежеланному «протеканию» данных. Используйте default=lambda self: [] или аналогично для словарей — это гарантирует новый объект при каждой инициализации.
Дефолты не запускают onchange
Значение по умолчанию не вызывает onchange-методов. Если у поля есть onchange, который обычно обновляет другие поля при ручном вводе, дефолт заполнит поле, но не запустит цепочку обновлений. Если вам нужно, чтобы эффект onchange был применён при инициализации, это надо делать явно — например, переопределив default_get или вызвав соответствующую логику вручную.
Конфликт дефолтов: ir.default vs. модель
Если дефолт задан и в коде, и через Studio (ir.default), приоритет будет на стороне ir.default. Это частая причина неожиданного поведения после правок в Studio: внешняя конфигурация тихо перекрывает дефолт, прописанный разработчиком в коде.
Дефолт ≠ требование заполнения
Наличие дефолта не делает поле обязательным. Пользователь в любой момент может очистить поле и сохранить запись пустым. Если вы действительно нуждаетесь в значении — комбинируйте дефолт с required=True или дополнительной проверкой сохранения.
Не хардкодьте ID компаний или пользователей
Дефолт вроде default=1, ссылающийся на запись по ID, ненадёжен: в другой базе у нужного пользователя или компании может быть другой ID. Используйте динамические ссылки: lambda self: self.env.company.id или self.env.ref('module.xml_id').id — так конфигурация остаётся переносимой.
Заключение
Значения по умолчанию — небольшая, но мощная возможность модели данных Odoo. Они уменьшают ручной ввод, направляют сотрудников к единому подходу и делают формы удобнее. Будь то быстрая правка через Studio или аккуратно продуманный дефолт в Python-модуле — правильно настроенные дефолты заметно улучшают повседневную работу с системой.
Главные тезисы: дефолты применяются только при создании записи; они не триггерят onchange; источников дефолтов несколько и у них есть порядок приоритета; изменяемые объекты всегда передавайте через лямбды, чтобы избежать нежелательного шаринга данных.
Грамотная настройка дефолтов часто определяет разницу между интуитивной формой и системой, которая постоянно тормозит пользователей. Небольшая инвестиция времени в продуманные дефолты окупается каждый рабочий день.
В компании Dasolo мы помогаем адаптировать, настраивать и оптимизировать Odoo под конкретные бизнес-процессы. Если вам нужна помощь с настройкой дефолтов полей, созданием кастомных полей или проектированием модели данных, мы готовы подключиться. Свяжитесь с нами и обсудим, как улучшить вашу реализацию Odoo.