Каждый проект Odoo рано или поздно сталкивается с одним и тем же вопросом: стандартный процесс почти подходит, но не совсем соответствует желаниям бизнеса. Изменить настройку, открыть Odoo Studio или попросить разработчика написать собственный модуль? От ответа надолго зависят стоимость, стабильность и прежде всего обновления.
В 1CBMS мы в каждом внедрении следуем простому правилу: сначала настройка, затем Studio, затем собственные модули. Каждая следующая ступень этой лестницы добавляет гибкости, но и добавляет то, чем бизнесу придётся владеть и что придётся сопровождать на протяжении всего срока жизни системы.
Об источниках: статья основана на официальной документации Odoo для версии 19.0. Меню и параметры могут различаться в зависимости от версии, редакции и типа размещения, поэтому всегда проверяйте поведение в тестовой базе данных, прежде чем вносить изменения в рабочую.
Уровень первый: прежде всего настройка
Odoo поставляется с большим количеством настроек, параметров и настраиваемых записей в каждом приложении. Многие запросы, похожие на доработки, на самом деле являются стандартными функциями, которые просто ещё не включены, например дополнительные этапы процесса, макеты документов или необязательные поля, появляющиеся после включения функции.
Прежде чем писать техническое задание для Studio или кода, пройдите вместе с ключевыми пользователями процесса следующие проверки:
- Просмотрите страницу «Настройки» каждого задействованного приложения и прочитайте, что включает каждый параметр.
- Проверьте, покрывается ли требование настраиваемыми записями, такими как этапы, теги, команды, типы операций или шаблоны писем.
- Для логотипов, цветов, шрифтов и нижних колонтитулов используйте настройки макета документов компании вместо редактирования шаблонов отчётов.
- Спросите, может ли бизнес адаптировать свой процесс к стандартному, ведь стандартные процессы тестирует и обновляет Odoo.
Настройка — самый дешёвый в сопровождении уровень. Она входит в стандартный продукт, переносится процессом обновления и не создаёт отдельной кодовой базы, которую кому-то придётся поддерживать.
Уровень второй: что умеет Odoo Studio
Документация Odoo описывает Studio как набор инструментов для доработки Odoo без знания программирования. Studio открывается значком «Переключить Studio», когда вы находитесь в приложении и модели, которые хотите изменить, и закрывается кнопкой «Закрыть».
Согласно официальной документации, Studio охватывает следующие области:
- Поля: простые поля, такие как текст, целое число, десятичное число, денежная сумма, дата, флажок, выбор из списка, файл и изображение, а также реляционные поля, такие как Many2One, One2Many, строки, Many2Many, теги и связанные поля.
- Представления: форма, действия, поиск, канбан, список, карта, календарь, когорта, диаграмма Ганта, сводная таблица и график.
- Модели и приложения: новые модели, создаваемые с нуля, с предлагаемыми функциями, такими как чат, этапы воронки, теги, архивирование и строки, ускоряющими создание.
- Правила автоматизации: триггеры на изменение значений, события электронной почты, временные условия, создание или удаление записей, изменения в интерфейсе и внешние вебхуки.
- Правила утверждения: этапы согласования, привязанные к кнопкам, с утверждающими в виде пользователей, групп или и тех и других. Studio также охватывает вебхуки и правила безопасности.
- PDF-отчёты: редактирование статического текста, вставка динамических полей, таблиц, столбцов и изображений в шаблоны отчётов; учтите, что редактирование верхнего или нижнего колонтитула отчёта влияет на все отчёты.
Когда вы меняете представление перетаскиванием, Studio автоматически создаёт соответствующее наследуемое представление и XPath, а не перезаписывает стандартное представление. Вся работа в Studio собирается в модуль studio_customization в вашей базе данных, который можно экспортировать в ZIP-файл и импортировать в другую базу данных.
Studio — приложение Odoo Enterprise. На официальной странице также отмечено, что установка Studio в базе данных на тарифе «Стандартный» влечёт переход на тариф «Индивидуальный», поэтому перед включением уточните коммерческие последствия у своего менеджера Odoo. В базах данных Community нет Studio; там всё, что выходит за рамки настройки, делается через технические настройки в режиме разработчика или с помощью модулей.
Уровень второй (продолжение): ограничения Studio
Studio — мощный инструмент, но сама документация указывает на ряд ограничений и рисков, которые следует учитывать в каждом проекте:
- Техническое имя поля нельзя изменить в Studio после создания, собственные поля должны иметь как минимум префикс x_, а поля Studio используют префикс x_studio_.
- Представление действий и условные блоки в отчётах можно изменить только редактированием XML, для чего нужен режим разработчика.
- Прямое редактирование стандартных или наследуемых представлений не рекомендуется, поскольку такие изменения будут сброшены и потеряны при обновлениях или обновлении модулей.
- Odoo настоятельно рекомендует дублировать стандартный отчёт и редактировать копию и предупреждает, что прямое изменение XML отчёта может вызвать проблемы при обновлениях.
- Действие «Выполнить код» в правилах автоматизации запускает Python, и в документации указано, что сопровождение собственного кода не входит в тарифы «Стандартный» и «Индивидуальный» и оплачивается дополнительно.
- Вебхуки следует проектировать с участием разработчика или технического специалиста, поскольку неправильно настроенные вебхуки могут нарушить работу базы данных.
- Экспортированные доработки Studio можно импортировать только в базу данных той же версии Odoo с тем же набором установленных приложений и модулей.
На практике Studio идеально подходит для ввода данных, макетов, простой автоматизации и согласований. Он становится рискованным, когда с его помощью прячут настоящее программирование в правках XML или действиях «Выполнить код», которые никто не документирует.
Уровень третий: когда оправдан собственный модуль на Python
Собственный модуль — это отдельная кодовая база, расширяющая Odoo с помощью моделей, представлений, правил безопасности, файлов данных и логики на Python и построенная на том же фреймворке, который Odoo использует для своих приложений. Это правильный инструмент, когда требование выходит за рамки того, что можно чисто выразить настройкой и Studio.
Типичные ситуации, в которых мы рекомендуем собственный модуль:
- Сложные бизнес-правила, расчёты или ограничения, требующие автоматических тестов и контроля версий.
- Интеграции с внешними системами, требующие надёжной обработки ошибок, повторных попыток и журналирования.
- Изменения стандартной бизнес-логики, например того, как проверяются документы или вычисляются значения, а не только того, как они отображаются.
Здесь важно размещение. В официальной документации указано, что Odoo Online несовместим с собственными модулями и модулями из Odoo Apps Store. Для собственных модулей нужен Odoo.sh или установка на собственном сервере, поэтому решение о размещении и стратегию доработок нужно принимать вместе.
Влияние каждого варианта на обновления
- Настройка: часть стандартного продукта, переносится стандартным процессом обновления.
- Studio: услуги обновления, описанные в документации Odoo, включают обновление всех доработок, созданных в приложении Studio, при условии что Studio установлен и подписка на него активна.
- Собственные модули: базу данных с собственными модулями нельзя обновить, пока для целевой версии Odoo не появится версия этих модулей, а обеспечение совместимости — ответственность того, кто сопровождает модуль.
Руководство Odoo по обновлению доработанной базы данных рекомендует заморозить разработку, проверить, какие собственные функции теперь доступны штатно, добиться чистой установки каждого модуля в пустую базу данных целевой версии, написать скрипты обновления для переименованных моделей, полей и внешних идентификаторов и отрепетировать обновление, прежде чем трогать рабочую систему.
На каком бы уровне ни была доработка, тщательно тестируйте обновлённую базу данных. Документация советует проверять бизнес-процессы от начала до конца, включая интеграции, автоматические действия, серверные действия и отчёты, и напоминает, что тестовые базы данных нейтрализованы: запланированные действия и исходящая почта в них отключены.
Управление: как держать доработки под контролем
Доработки редко ломаются в первый же день. Они ломаются спустя годы, когда никто уже не помнит, зачем существует поле или кто написал правило автоматизации. Лёгкая модель управления предотвращает это.
- Ведите реестр доработок, в котором перечислены все поля Studio, изменения представлений, правила автоматизации, правила утверждения, отчёты и собственные модули с указанием ответственного и бизнес-причины.
- Вносите все изменения сначала в тестовую или staging-базу данных, а затем переносите их в рабочую по контролируемой процедуре.
- Ограничьте доступ к Studio и режиму разработчика обученными администраторами; сама документация предупреждает, что некоторые инструменты разработчика сложны и сопряжены с рисками.
- Перед каждым обновлением пересматривайте реестр и выводите из эксплуатации доработки, которые новая версия покрывает штатно.
- Храните код собственных модулей в системе контроля версий вместе с тестами и убедитесь, что для него предусмотрено сопровождение.
Матрица решений для рабочих встреч
Когда появляется новое требование, мы проходим по этим вопросам по порядку и останавливаемся на первом уровне, который его удовлетворяет.
- Можно ли закрыть потребность стандартной настройкой, настраиваемой записью или изменением процесса? Используйте настройку.
- Это новое поле, изменение макета представления, простая автоматизация, этап согласования или изменение формулировок в отчёте? Используйте Studio.
- Нужны ли логика на Python, автоматические тесты, сложная интеграция или повторное использование в нескольких базах данных? Используйте собственный модуль.
- База данных размещена в Odoo Online? Оставайтесь в рамках настройки и Studio или сначала спланируйте переход на Odoo.sh или собственный сервер.
Чем может помочь 1CBMS
1CBMS помогает компаниям в Египте и Ираке проектировать решения на Odoo 19 Enterprise, максимально близкие к стандарту. Мы проводим fit-gap-сессии, чтобы отделить настройку от реальных пробелов, выполняем дисциплинированные доработки в Studio, разрабатываем и сопровождаем собственные модули, когда они действительно нужны, и готовим реестры доработок и планы тестирования обновлений, чтобы ваша система оставалась удобной в сопровождении. Свяжитесь с нами через www.1cbms.com, чтобы проанализировать текущие доработки или спланировать новое внедрение.