Boolean Field в Odoo: Полное руководство по использованию и настройке

Введение

Логическое (Boolean) поле — один из самых простых и при этом самых частых типов данных в Odoo. Каждый раз, когда вы ставите галочку в заказе продаж, отмечаете клиента как активного или помечаете товар «в избранном», вы фактически меняете логическое поле.

Несмотря на свою простоту, у логического поля есть повадки, которые лучше понимать заранее. Правильный выбор, настройка и использование таких полей помогают держать модель данных аккуратной и избегать ошибок, с которыми даже опытные команды иногда сталкиваются.

Этот материал рассматривает логическое поле со всех сторон: что в нём хранится, как оно отображается в интерфейсе и в модели данных, как его добавить через Studio или код, где рационально применять и какие практические нюансы учитывать.

Что такое логическое поле в Odoo

В ORM Odoo логическое поле может принимать лишь два состояния: True или False. На уровне базы данных оно ложится в колонку типа BOOLEAN. Никакой полутоновости — значение либо установлено, либо нет.

Для пользователя логическое поле обычно выглядит как чекбокс в форме. В табличном (list) виде оно чаще показывается иконкой галочки для True и пустым местом для False. В некоторых местах интерфейса вместо галочки применяется переключатель — это зависит от виджета, назначенного полю.

Ниже — пример того, как логическое поле объявляют в модуле на Python:

from odoo import fields, models

class SaleOrder(models.Model):
    _inherit = 'sale.order'

    needs_manual_review = fields.Boolean(
        string='Needs Manual Review',
        default=False,
    )

Параметр string задаёт метку, которую увидит пользователь. Параметр default определяет начальное значение для новых записей. Хотя ORM без явного default всё равно вернёт False, явное указание значения повышает читабельность кода и снимает вопросы у коллег.

В Odoo Studio аналог этого типа называют просто Checkbox. Поля, созданные через Studio, получают префикс x_studio_ в техническом имени. Если вы создаёте поле в коде или через API, техническое имя задаёте сами.

Как оно работает

При добавлении логического поля в модель Odoo создаёт соответствующую колонку в PostgreSQL автоматически при установке или обновлении модуля — дополнительных SQL-миграций делать не нужно.

Важно помнить: логическое поле в Odoo никогда не возвращает NULL/None. При чтении вы всегда получите либо True, либо False. Даже если в базе нет явного значения, ORM вернёт False. Это отличается от других полей, где пустое значение может быть None и потребовать дополнительной проверки.

Ключевые атрибуты поля

Ниже перечислены основные свойства, которыми обладает логическое поле в Odoo и которые можно настроить в модели:

• default: задаёт значение при создании записи. Обычно False, но может быть True для сценариев с отказом по умолчанию.
• compute: связывает поле с методом Python, который вычисляет значение динамически — удобно для флагов, зависящих от состояния других полей.
• store: в связке с compute указывает, сохраняется ли вычисленное значение в базе. При store=True поле можно использовать в фильтрах и отчётах.
• readonly: делает поле недоступным для ручного редактирования в интерфейсе — часто используют для вычисляемых системных флагов.
• copy: управляет копированием значения при дублировании записи. По умолчанию True; для флагов вроде «утверждён» обычно ставят copy=False, чтобы дубликат был «чистым».
• groups: ограничивает видимость и редактирование поля для конкретных групп пользователей.

Как поле выглядит в представлениях

В формах логическое поле рендерится как обычный HTML-чекбокс. В списках по умолчанию отображается галочка для True и пусто для False — это упрощает визуальный обзор записей.

Отображение можно менять через виджеты: toggle превращает чекбокс в переключатель, что удобно для настроек; boolean_favorite показывает звёздочку, как на карточке товара — это удобно для отметки предпочтений.

Применение в доменах и фильтрах

Логические поля отлично подходят для доменов — выражений фильтрации в поисках, автоматических действиях и правилах доступа. Пример фильтра для отмеченных записей:

[('needs_manual_review', '=', True)]

Поскольку значений всего два, фильтры просты и однозначны.

[('needs_manual_review', '=', False)]

Такая предсказуемая логика делает логические поля удобными для автоматизаций: их легко проверять и на их основе запускать действия без сложных условий.

Взаимодействие с ORM

Чтение и запись логических полей в разработке максимально просты: берёте значение у объекта-записи, сравниваете с True/False и присваиваете новое значение. ORM сам позаботится обо всём, включая корректную передачу через XML-RPC.

Бизнес-сценарии применения

Где применяются в реальных бизнесах

Логические поля встречаются во всех отделах — от продаж до HR. Ниже — пять практических сценариев, где они оказываются полезными.

CRM — пометка квалифицированного лида

Командам продаж бывает удобно быстро отметить лиды, которые уже пройдены и признаны перспективными. Поле вроде is_qualified позволяет отделить ковровые лиды для младших сотрудников от приоритетных для опытных менеджеров без введения дополнительной стадии в воронке.

Продажи — заказы, требующие ручной проверки

В компаниях, где некоторые заказы требуют проверки (по сумме, по клиенту и т.д.), поле needs_manual_review даёт четкую очередь для финансов или операционного отдела. Автоматическое правило может выставлять этот флаг, а команда фильтрует список по этому полю и последовательно обрабатывает заявки.

Склад — товар снят с продажи

Если товар больше не продаётся, но его нужно сохранить в базе для истории, вместо архивации можно использовать поле is_discontinued. Оно подскажет закупкам и продажам не предлагать и не заказывать товар, и его удобно использовать в фильтрах прайс-листов или настройках видимости в интернет-магазине.

Бухгалтерия — счёта под спором

Финансы часто отмечают счета, которые оспариваются или ожидают корректировки. Поле under_dispute структурирует эту информацию и позволяет исключить такие счета из автоматических напоминаний об оплате, чтобы не давить на клиента до разрешения вопроса.

HR — подтверждение прохождения обучения

Создание и настройка логического поля

Отделы кадров используют логические поля, чтобы фиксировать выполнение обязательных тренингов или наличие сертификатов. Поле вроде safety_training_completed даёт менеджерам быстрый фильтр по сотрудникам, у которых ещё не пройдено обязательное обучение, и упрощает отчётность по соответствию требованиям.

Три способа добавить логическое поле в модель Odoo

Выбор подхода зависит от вашего уровня доступа и требований к контролю версий: можно сделать через Studio без кода, прописать в модуле на Python или создать поле программно через API.

1. Через Odoo Studio (без кода)
2. Studio — встроенный инструмент для быстрого кастома без Python или XML. Чтобы добавить поле через Studio:
3. Откройте Odoo Studio (нужен установленный модуль Studio).
4. Перейдите на форму, куда хотите вставить поле.
5. Перетащите Checkbox из панели элементов на форму.

Укажите метку, значение по умолчанию и нужные ограничения в панели свойств.

Сохраните изменения и закройте Studio.

Studio автоматически создаст поле в базе с префиксом x_studio_ и добавит его во view — перезапуск системы не требуется.

Через Python в кастомном модуле

Для разработчиков поля объявляют в Python-файлах модели — это лучший путь, если нужно версионирование, тесты и деплой в нескольких средах:

from odoo import fields, models class ResPartner(models.Model): _inherit = 'res.partner' x_is_key_account = fields.Boolean( string='Key Account', default=False, copy=False, )

После объявления поле добавляют в XML-представление, чтобы оно стало видимым. Колонка в базе появится при установке или обновлении модуля.

Для вычисляемых логических полей используют такой шаблон:

from odoo import api, fields, models class SaleOrder(models.Model): _inherit = 'sale.order' is_high_value = fields.Boolean( string='High Value Order', compute='_compute_is_high_value', store=True, ) @api.depends('amount_total') def _compute_is_high_value(self): for order in self: order.is_high_value = order.amount_total >= 10000

При store=True вычисленное значение сохраняется в базе, что позволяет использовать поле в поиске и группировках без постоянных перерасчётов при загрузке страниц.

Через XML-RPC API

Если вы автоматизируете конфигурацию удалённо или в пайплайне развёртывания, поле можно создать через XML-RPC, работая с моделью ir.model.fields:

Рекомендации по использованию

field_id = models.execute_kw( ODOO_DB, uid, ODOO_API_KEY, 'ir.model.fields', 'create', [{ 'name': 'x_needs_manual_review', 'field_description': 'Needs Manual Review', 'model_id': model_id, 'ttype': 'boolean', 'state': 'manual', }] )

Параметр state: 'manual' сигнализирует, что поле создано вне модуля — корректная настройка для полей Studio или API. Такой подход удобен при централизованной автоматической конфигурации клиентов.

Лучшие практики

1. Всегда указывайте default

Хотя ORM вернёт False при отсутствии явного default, прописывание default=False в определении поля делает намерение очевидным и предотвращает недоразумения при автоматизациях и при чтении кода.

2. Давайте понятные имена, которые читаются как вопрос

Имена вроде is_verified, needs_approval, has_warranty или is_key_account сразу говорят, что поле отражает булево состояние. Избегайте неопределённых названий вроде flag или status — они ничего не объясняют.

3. Для флагов статуса ставьте copy=False

Если поле означает уже совершённое действие (утверждён, отправлен и т.п.), обычно не нужно, чтобы оно копировалось при дублировании записи. copy=False предотвращает попадание дубликата в «утверждённое» состояние по ошибке.

4. Для производных состояний используйте computed-поля

Типичные ошибки

Вместо разбросанных серверных действий, вручную обновляющих флаг, лучше сделать computed-поле с @api.depends(). Это концентрирует логику в одном месте, гарантирует актуальность при сохранении записи и упрощает поддержку.

5. Добавляйте поле в поисковые представления, если его используют для фильтрации

Если пользователи часто фильтруют записи по булевому полю, внесите его в search-view — так появится удобный переключатель в строке поиска, а не придётся каждый раз открывать расширенные фильтры.

Обычные ошибки и как их избежать

Использование булева поля для состояния с более чем двумя вариантами

Самая частая ошибка — пытаться моделировать трёх- или многостояничное состояние булевыми флагами. Если у вас «ожидает», «утверждён», «отклонён», применяйте Selection-поле или полноценный workflow, а не несколько булевых полей — иначе логика быстро станет запутанной.

Забыть поставить copy=False для флагов утверждения

По умолчанию при дублировании все поля копируются. Если флаг отражает факт завершённого процесса, он не должен переноситься на дубликат — не забудьте copy=False.

Не добавить поле в search-view

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

Заключение

Использовать булево поле вместо стандартного active

Во многих моделях уже есть системное поле active для управления видимостью записей. Если задача — скрыть/показать запись, лучше использовать native active, чтобы не ломать встроенные механизмы архивации и фильтры Odoo.

Вычисляемые булевые поля без store=True в фильтрах

Если вычисляемое булево поле не сохраняется в базе (store=False), вы не сможете на нём фильтровать или группировать данные в SQL-запросах — Odoo либо выдаст ошибку, либо проигнорирует фильтр. Для фильтруемых вычисляемых полей всегда ставьте store=True. Итог Логическое поле — тот элемент, который перестаёшь замечать, потому что оно делает свою работу надёжно. Оно повсюду: от видимости записей (active) до флагов публикации на сайте и множества пользовательских отметок в процессах.