OdoMate
Odoo Studio запускає справжній Python-код, а не просто малює форми й кнопки — тому серед п'яти шляхів кастомізації Odoo вона стоїть окремо. Але можливості Studio мають межу, і ця межа виявляється трьома різними способами: значення, яке мусить самостійно перераховуватися правильно незалежно від порядку подій; багатокроковий процес, що вимагає повного завершення або повного відкату — без проміжного стану; і деякі події — перегляд запису чи його експорт — для яких у Studio взагалі немає тригера. Різниця між трьома категоріями не у важливості, а в тому, наскільки далеко кожна від того, що Studio спроможна зробити.
Ключові висновки
- Питання не в тому, чи «достатньо хороша» Studio загалом, а в тому, де саме проходить її межа для конкретної функції.
- Три приклади нижче показують це по-різному: у першому функціонал вдається фактично закрити можливостями Studio, без стороннього модуля; у другому Studio впирається точно в межу своїх можливостей; третій — випадок, що лежить повністю поза межами того, що Studio здатна зробити.
- Помилка може стати справді дороговартісною, якщо побудувати код, що мовчки залежить від поля, яке створила Studio, — така залежність ламається на першій-ліпшій чистій базі даних.
Нижче розберемо приклади модулів, які OdoMate згенерував за специфікацією, — і чи вдалося б закрити ту саму потребу засобами Odoo Studio замість стороннього модуля.
Що Odoo Studio насправді вміє будувати?
Власник бізнесу може в Studio:
- створити нову модель і поля
- зібрати список та форму
- налаштувати права доступу
- написати правило автоматизації, яке під капотом запускає справжній Python
Кожна зміна лягає в таблиці ir.model.fields та ir.ui.view — і саме тому, за документацією Odoo, кастомізацію Studio можна експортувати як звичайний модуль. Цей набір інструментів закриває широкий діапазон бізнес-запитів.
Де проходить стеля можливостей Studio?
Спроможність Studio рідко буває вирішальним фактором при виборі способу кастомізації, але іноді стає ним. Нижче — три реальні вимоги: перша здебільшого вписується в можливості Studio, друга впирається точно в її межу, а третя лежить повністю поза нею.
Чек-лист завдань: Studio доводить майже до фінішу
Бізнес-задача: чек-лист зі стандартними кроками для завдання проєкту, який показує прогрес виконання і сам виставляє дату завершення. Під цю вимогу OdoMate згенерував модуль odomate_project_checklist — шаблон чек-листа, кроки, статуси, форми перегляду й редагування.
Studio покриває майже весь цей список. Зупиняється Studio там, де значення мусить самостійно перераховуватися правильно незалежно від порядку подій — і саме тут правило, побудоване лише в Studio, не витримує: таке правило реагує тільки на ті переходи, які хтось наперед налаштував. Налаштуй правило на подію «крок завершено» і забудь про зворотне — і повторне відкриття вже завершеного кроку залишить дату завершення тією самою, що була в день першого завершення: мовчки неправильною, бо ніхто не сказав Studio її скинути. Реальний модуль робить це правильно: його прогрес перераховується за будь-якої зміни, в обидва боки, тож дата завершення завжди показує те, що є правдою зараз.
Глибший розбір цього модуля порівняно з готовим рішенням з Apps Store — у статті «Чи може згенерований ШІ-модуль Odoo зрівнятися з модулем з Apps Store».
Автоматичне виконання замовлення: точна межа
Бізнес-задача: одним натисканням кнопки «Confirm» на замовленні клієнта запустити повний ланцюжок — підтвердити доставку, створити рахунок, провести рахунок, — і не лишити недороблений слід, якщо щось на цьому шляху зірветься. Під цю вимогу OdoMate згенерував модуль sale_warehouse_auto_fulfillment.
Studio здатна з'єднати ці три кроки в ланцюжок правилами автоматизації. Гарантувати, що весь ланцюжок виконається повністю або відкотиться, без проміжного стану, Studio не може. Наслідок збою на останньому кроці: ланцюжок, побудований у Studio, лишає доставку вже підтвердженою, а замовлення зависає на півдорозі: відвантаження без рахунка або частковий слід, який ніхто не помічає до звірки. Причина не в недоліку автоматизацій Studio — а в тому, що ланцюжок із декларативних дій (онови це, створи те) не дає гарантії «або все, або нічого». У Studio можна написати справжній Python-код через дію Execute Code, але тоді це вже кастомний код з тією ж відповідальністю за оновлення, що й у модуля, — а не налаштування точка-і-клік.
Глибший розбір модуля порівняно з модулем стороннього постачальника з тим самим набором функцій — у статті «Автоматизація замовлень на продаж в Odoo: згенерований модуль проти модуля постачальника».
Журнал аудиту: шляху через Studio немає взагалі
Бізнес-задача: вести історію на рівні запису — хто, що і коли зробив, включно з діями, які ніколи не показуються як «зміна»: вивантаження даних у таблицю або сам факт відкриття чутливого запису кимось. Під цю вимогу OdoMate згенерував модуль audit_trail.
Правила автоматизації Studio спрацьовують лише на події створення, оновлення чи видалення запису; читання чи експорт запису не є тригером — такого тригера в Studio просто немає, тому закрити такий запит через Studio — неможливо.
Як порівнюються три приклади?
| Вимога | Наскільки покриває Studio | Де саме ламається | Модуль |
|---|---|---|---|
| Чек-лист завдань | Здебільшого | Правило лише в Studio лишає застарілу, неправильну дату завершення після повторного відкриття кроку | odomate_project_checklist |
| Автоматичне виконання замовлення | Лише просте ланцюжкове з'єднання кроків | Збій на кроці лишає напівдороблене відвантаження або рахунок-сироту | sale_warehouse_auto_fulfillment |
| Журнал аудиту | Ні | Перегляди й експорти запису не лишають сліду — реагувати нема на що | audit_trail |
Що стається, коли власний код залежить від поля Studio?
Studio нерідко доводить розробку кастомізації майже до завершення, перш ніж впертись в обмеження інструменту — і саме на цьому кроці виникає спокуса дописати власний код, який читає поле, створене Studio. Код працює, бо в конкретній базі даних це поле існує.
Проблема виникає згодом, і одразу в кількох місцях:
- Модуль не встановлюється на чистій базі даних — клоні тестового середовища, новій компанії, машині колеги, — бо там цього поля просто немає.
- Відновити середовище можна лише спершу відтворивши експорт Studio, і саме в правильному порядку.
- Перейменувати те поле можна лише поза Studio — офіційна документація Odoo описує, що спершу поле треба прибрати з усіх форм, змінити технічну назву в «Налаштування → Технічне → Поля», а тоді додати назад у кожну форму вручну. Пропустиш цей крок — і модуль лишається прив'язаним до тієї назви, яку колись згенерував підпис форми.
- Відповідальність за наступне оновлення розділяється навпіл усередині однієї функції: частина лягає на бік Odoo, частина — на власний код.
Власна інструкція розробника Odoo прямо радить перевіряти кастомні модулі на порожній базі даних — і серед проблем, які такий тест ловить ще до продакшена, називає саме кастомізацію Studio.
Правило з цього випливає просте: для кожної функції обирати один бік — або налаштовувати повністю в Studio, або будувати повністю модулем із власними полями. Модуль, що читає поле Studio, створює залежність, яку не бачать ні маніфест модуля, ні історія Git — її не зловлять навіть власні автотести модуля, бо поле існує лише в базах, де вже хтось запустив експорт Studio.
Як обрати між Studio і кастомним модулем?
Три запитання варто поставити для кожної окремої вимоги, а не для проєкту загалом:
- Чи потрібно значенню самостійно перераховуватися правильно незалежно від порядку подій, або витримати збій на проміжному кроці? Якщо так — вимога вже за межею того, що можуть гарантувати правила автоматизації Studio.
- Чи потрібно реагувати на подію, яку Odoo взагалі не вважає «зміною» — наприклад, на сам факт перегляду або експорту запису? Правила Studio спрацьовують лише на створення, оновлення й видалення.
- Якщо Studio доводить розробку майже до кінця — чи читатиме створене нею поле щось інше в системі? Якщо так, варто одразу визначити: ця частина або повністю в Studio, або повністю в кастомному модулі — а не ділити її навпіл пізніше.
Тільки Studio, чи тільки кастомний модуль, не є правильною відповіддю сама по собі — вибір робиться свідомо, під конкретну вимогу. Ширшу картину п'яти шляхів кастомізації дає перша стаття серії, «Кастомізація Odoo: ваші варіанти», а звузити вибір допомагає інструмент прийняття рішень.
Хочете перевірити подібну вимогу на власній специфікації — подайте заявку на ранній доступ. Ми розглядаємо заявки поступово й підключаємо невеликими групами.
FAQ
Чи доступна Odoo Studio на редакції Community?
Ні. Studio працює лише на Enterprise — встановлення Studio на плані Standard автоматично переводить підписку на план Custom, а в дереві вихідного коду Community модуля web_studio просто немає.
Чи може кастомний модуль читати поле, створене в Studio? Технічно так, але це погана ідея. Жоден маніфест не вміє задекларувати таку залежність, тому наслідки несподівано з'являються пізніше: модуль не встановлюється на чистій базі даних, відновлення середовища вимагає відтворення експорту Studio в правильному порядку, перейменувати поле можна лише вручну поза Studio, а відповідальність за оновлення розділяється навпіл. Розділ вище про залежність від поля Studio розбирає це детальніше.
Чи виконує Studio справжній код? Так. Кожна модель, поле, форма чи правило автоматизації, створені в Studio, під капотом запускають реальний Python — Studio лише зберігає результат як записи в базі даних, а не як окремі файли.
Чого Studio не вміє взагалі? Три категорії: значення, яке мусить лишатися коректним через непередбачену послідовність подій; багатокроковий процес, що потребує повного завершення або повного відкату; реакцію на подію, для якої в Studio немає тригера — наприклад, на сам перегляд чи експорт запису. Три реальні приклади розібрано вище в статті.
Studio чи кастомний модуль — що обрати? Залежить від конкретної вимоги, а не від того, наскільки хороша Studio загалом. Варто перевірити, чи вимагає завдання гарантій, яких правила автоматизації Studio дати не можуть: самокорекції значень, виконання «все або нічого», реакції на подію без тригера. Якщо роботу ділять між Studio і кастомним модулем, модулю не можна дозволяти залежати від поля, яке створила Studio.