Пользовательские поля в Odoo: Полное руководство

Каждая компания хранит свои уникальные данные — те, что не входят в стандартное ПО. Именно для таких случаев в Odoo существуют пользовательские поля: простой способ добавить нужные данные прямо в систему, не ломая процессы.

Вместо того чтобы подстраивать работу команды под жесткую структуру данных, в Odoo можно дополнять почти любую запись новыми полями — будь то контрагент, заказ, товар или счёт. Вы решаете, что хранить, а система размещает это рядом со стандартными полями.

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

Что такое пользовательское поле в Odoo

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

В Odoo такие поля помечаются префиксом x_. Поля, созданные через Studio, обычно получают имена вроде x_studio_priority_level, а при программном добавлении разработчики могут использовать собственный префикс, например x_acme_cost_center.

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

Доступные типы полей

Odoo поддерживает множество типов полей, покрывающих большинство бизнес-потребностей:

• Текст (Char): короткие строки — коды, метки, короткие описания
• Длинный текст: многострочные заметки, пояснения
• Целое (Integer): количества, счетчики, баллы
• Дробное (Float): измерения, коэффициенты, показатели с точностью
• Денежное (Monetary): суммы в валюте, связаны с полем валюты
• Логическое (Boolean): да/нет, чекбокс
• Дата / Дата и время: календарные даты и временные метки
• Выбор (Selection): фиксированный список вариантов в выпадающем меню
• Many2one: ссылка на одну запись из другой модели
• One2many: список связанных записей из другой модели
• Many2many: несколько связанных записей из другой модели
• Binary: вложение файла
• HTML: форматированный текст с разметкой

Правильный выбор типа поля с самого начала экономит время. Если набор допустимых значений известен — лучше использовать Selection, чем свободный текст, чтобы избегать ошибок ввода и разнобоя в отчётах.

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

Odoo построен на ORM (Object-Relational Mapping). Каждой форме и записи соответствует Python-модель, которая связана с таблицей в PostgreSQL. При добавлении пользовательского поля Odoo регистрирует его в ORM и автоматически создаёт соответствующий столбец в базе данных.

Именно метаданные делают модель гибкой: вы не меняете исходный код, а расширяете модель через таблицу ir.model.fields. Odoo читает эту таблицу при запуске и динамически подгружает поля в модели.

Поля в коде против полей, созданных в базе

В классической разработке Odoo поля прописывают в Python-классах модели, используя встроенные типы фреймворка. Такой подход даёт явную структуру в коде и удобен для поддержки.

Пример типичной декларации поля в модуле на Python:

Поля, созданные через UI или API, записываются в ir.model.fields с отметкой state = 'manual' и загружаются во время выполнения. С точки зрения пользователя и базы это приводит к появлению реального столбца, и оба подхода работают одинаково в интерфейсе.

Отношения между моделями и взаимная связь

Если вы добавляете Many2one-поле, указывающее на другую модель, корректно ожидается соответствующее One2many на противоположной стороне. Это не формальность — ORM использует такие связи для навигации между записями.

Например, если на заказ добавлено поле x_project_id (Many2one на project.project), логично иметь поле x_sale_order_ids (One2many обратно на sale.order) в модели проекта. Без этого стандартный интерфейс не позволит удобно перейти от проекта к связанным заказам.

Вычисляемые (computed) поля

Вычисляемые поля в Odoo получают значение автоматически на основе других полей. В коде вы определяете метод и связываете его с полем через параметр compute. Такие поля обычно только для чтения и обновляются при изменении зависимостей.

Вычисляемые поля даются через код и требуют навыков Python; создать их целиком через Studio без включения режима разработчика нельзя.

Примеры использования в бизнесе

Пользовательские поля встречаются в большинстве реальных проектов. Ниже — пять практических сценариев использования, встречающихся у наших клиентов.

1. CRM: более точная квалификация лидов

Стандартные лиды содержат базовую информацию, но часто нужны дополнительные характеристики. Например, поле Selection «Отрасль клиента» или Many2one на внутреннюю модель «Сегмент рынка» помогает менеджерам быстрее квалифицировать лиды и строить отчеты по сегментам продаж.

2. Продажи: привязка внутренних кодов проектов

Если вы выставляете счета по проектам, удобно прикреплять к коммерческим предложениям и заказам внутренний код проекта или ссылку на бюджет. Простое Char-поле «Код проекта» в sale.order решает задачу без внедрения полной системы управления проектами: поле печатается в документах и участвует в фильтрах и отчетах.

3. Склад: технические атрибуты товара

Помимо стандартных атрибутов, производителям и дистрибьюторам часто нужны отраслевые характеристики: гарантийный срок (Integer), стандарт сертификации (Selection) или страна производства (Many2one на res.country). Такие поля интегрируются в карточку товара и видны в отчетах по запасам.

4. Бухгалтерия: распределение по центрам затрат

Финансисты нередко помечают счета и проводки кодом центра затрат или строкой бюджета. Many2one на модель «Центр затрат» в account.move позволяет гибко учитывать затраты без перестройки аналитического учета — фильтры и сводные таблицы начинают работать сразу после добавления поля.

5. HR: данные при адаптации сотрудников

HR собирает много специфичной информации при приёме: локальные типы контрактов, внутренние категории навыков, привязка к автопарку. Пользовательские поля в hr.employee хранят это прямо в системе, а не в отдельных таблицах или Excel, делая данные доступными для поиска и отчетности.

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

Два способа добавить поле в Odoo: через интерфейс без кода и через код. Выбор зависит от уровня сложности и возможностей команды.

Вариант 1: Odoo Studio — без программирования

Studio — самый быстрый путь для пользователей. С включённым Studio новое поле добавляют за несколько кликов:

1. Откройте нужное приложение и форму, где будет поле (например, форму заказа)
2. Нажмите иконку редактирования, чтобы войти в режим Studio
3. Перетащите тип поля из левой панели на форму
4. Задайте метку, техническое имя и дополнительные свойства поля
5. Сохраните и выйдите из Studio

Studio создаёт запись в ir.model.fields с префиксом x_studio_ и вставляет поле в вид. Перезапуск сервера не требуется — это удобно для простых полей без логики.

Вариант 2: техническая кастомизация через API или модуль

Когда нужна сложная логика, вычисления, домены или контроль версий, поля создают программно — через XML-RPC API или как часть Python-модуля. Это правильный путь для проектов, где всё хранится в системе контроля версий и развёртывается как код.

Пример создания поля Selection на заказ через API выглядит так:

(в примере показан поиск модели sale.order и создание записи в ir.model.fields с указанием типа, вариантов выбора и состояния manual)

Это стандартная практика разработчиков Odoo для добавления полей без изменения исходных файлов — удобно для удалённой конфигурации и автоматизированного развёртывания.

Если вы делаете полноценный модуль, поля определяются в Python-классе и подключаются как обычный модуль Odoo. Такой подход предпочтителен для поддерживаемых и обновляемых решений.

Добавление поля в вид

Создание поля не гарантирует его отображение: нужно вставить поле в нужную форму или список. В Studio это делается одновременно с созданием поля. При кодовой кастомизации вы правите XML-вью или создаёте наследуемый вид, который добавляет поле в нужное место.

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

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

Используйте Selection вместо свободного текста

Если варианты заранее известны — выбирайте Selection. Свободный текст приводит к множественным вариантам написания ("Клиент", "клиент", "client") и ломает фильтры и отчёты. Выпадающий список решает проблему в корне.

Давайте полям понятные и постоянные имена

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

Не перегружайте стандартные модели

Если на sale.order появляется десять полей, возможно, это сигнал о необходимости отдельной модели. Когда набор полей описывает самостоятельную сущность (проект, контракт, сертификат), лучше сделать отдельную модель и связать её Many2one-полем.

Всегда тестируйте на стейджинг-окружении

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

Документируйте пользовательские поля

Ведите реестр: модель, техническое имя, назначение, кто запросил. С ростом системы число полей увеличивается, и без документации вскоре станет непонятно, какие из них ещё используются.

Используйте подходящие инструменты для вычисляемой логики

Если значение поля вычисляется из других данных — делайте его вычисляемым, а не полагайтесь на ввод пользователя. Это уменьшает ошибки и гарантирует согласованность данных; вычисляемые поля — стандартная функция Odoo в Python.

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

Даже опытные команды сталкиваются с повторяющимися проблемами. Ниже — самые частые ошибки при работе с пользовательскими полями.

Забыли прописать обратное One2many при создании Many2one

Частая техническая ошибка: создали Many2one ссылающееся на модель B, но не сделали соответствующее One2many в модели B. В результате со стороны B нельзя увидеть связанные записи A через стандартный интерфейс. Всегда создавайте пару полей одновременно.

Удаление поля с данными

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

Создание полей напрямую в продакшене

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

Конфликты имён с будущими стандартными полями

Odoo не допустит дублирования имени в текущей модели, но позже модуль может добавить поле с тем же именем и затенить ваше. Использование фирменного префикса (например, x_acme_) снижает риск конфликтов при установке новых модулей.

Добавление поля в форму без учёта UX

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

Несогласованное смешение Studio и кода

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

Итоги

Пользовательские поля — простой и эффективный способ подогнать Odoo под реальные бизнес-процессы. Они не требуют правки исходников, интегрируются в платформу и дают точную захватку данных без костылей.

Главное — планировать: выбирать подходящий тип поля, давать понятные имена, соблюдать правила для реляционных полей и документировать изменения. Хорошая архитектура полей делает систему проще в сопровождении и масштабировании по мере роста компании.

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

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

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