Розділ 12: Додавання Sprinkles

Наш модуль нерухомості тепер має сенс з точки зору бізнесу. Ми створили спеціальні представлення, додали кілька кнопок дій та обмежень. Однак наш інтерфейс користувача все ще трохи грубий. Ми хотіли б додати деякі кольори до представлень списків і змусити деякі поля та кнопки умовно зникнути. Наприклад, кнопки „Продано“ та „Скасувати“ мають зникнути, коли майно продано або скасовано, оскільки на даний момент більше не можна змінювати стан.

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

Посилання: документацію, пов’язану з цим розділом, можна знайти в Представлення.

Вбудовані представлення

Примітка

Ціль: наприкінці цього розділу слід додати певний список властивостей до перегляду типу властивості:

У модулі нерухомості ми додали список пропозицій нерухомості. Ми просто додали поле offer_ids з:

<field name="offer_ids"/>

Поле використовує спеціальне подання для estate.property.offer. У деяких випадках ми хочемо визначити окреме представлення списку, яке використовується лише в контексті подання форми. Наприклад, ми хотіли б відобразити список властивостей, пов’язаних із типом власності. Однак для ясності ми хочемо відобразити лише 3 поля: назва, очікувана ціна та стан.

Для цього ми можемо визначити вбудовані представлення списку. Вбудоване подання списку визначається безпосередньо в поданні форми. Наприклад:

from odoo import fields, models

class TestModel(models.Model):
    _name = "test_model"
    _description = "Test Model"

    description = fields.Char()
    line_ids = fields.One2many("test_model_line", "model_id")


class TestModelLine(models.Model):
    _name = "test_model_line"
    _description = "Test Model Line"

    model_id = fields.Many2one("test_model")
    field_1 = fields.Char()
    field_2 = fields.Char()
    field_3 = fields.Char()

<form>
    <field name="description"/>
    <field name="line_ids">
        <tree>
            <field name="field_1"/>
            <field name="field_2"/>
        </tree>
    </field>
</form>

У представленні форми test_model ми визначаємо конкретне представлення списку для test_model_line з полями field_1 і field_2.

Приклад можна знайти тут.

Exercise

Додайте вбудоване представлення списку.

• Додайте поле One2many property_ids до моделі estate.property.type.

• Додайте поле у вікні форми estate.property.type, як показано в Цілі цього розділу.

Віджети

Посилання: документацію, пов’язану з цим розділом, можна знайти в Віджети поля.

Примітка

Ціль: у кінці цього розділу стан властивості має відображатися за допомогою спеціального віджета:

Відображаються чотири стани: Новий, Пропозиція отримана, Пропозиція прийнята та Продано.

Щоразу, коли ми додавали поля до наших моделей, нам (майже) ніколи не доводилося турбуватися про те, як ці поля виглядатимуть в інтерфейсі користувача. Наприклад, для поля Date передбачено засіб вибору дати, а поле One2many автоматично відображається у представленні списку. Odoo вибирає правильний „віджет“ залежно від типу поля.

Однак у деяких випадках нам потрібно конкретне представлення поля, яке можна зробити завдяки атрибуту widget. Ми вже використовували його для поля tag_ids, коли використовували атрибут widget="many2many_tags". Якби ми його не використовували, то поле відображалося б у представленні списку.

Кожен тип поля має набір віджетів, які можна використовувати для точного налаштування його відображення. Деякі віджети також мають додаткові параметри. Вичерпний список можна знайти в Віджети поля.

Exercise

Використовуйте віджет рядка стану.

Використовуйте віджет statusbar, щоб відобразити state estate.property, як показано в Цілі цього розділу.

Порада: простий приклад можна знайти тут.

Попередження

Те саме поле кілька разів у представленні

Додайте поле лише один раз до списку або представлення форми. Додавання кілька разів не підтримується.

Порядок списку

Посилання: документацію, пов’язану з цим розділом, можна знайти в Моделі.

Примітка

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

Під час попередніх вправ ми створили кілька представлень списку. Однак ми жодного разу не вказали, у якому порядку записи повинні бути перераховані за замовчуванням. Це дуже важлива річ для багатьох бізнес-кейсів. Наприклад, у нашому модулі нерухомості ми хотіли б відображати найвищі пропозиції на початку списку.

Модель

Odoo пропонує кілька способів встановлення порядку за замовчуванням. Найпоширенішим способом є визначення атрибута _order безпосередньо в моделі. Таким чином, отримані записи дотримуватимуться детермінованого порядку, який буде узгодженим у всіх поданнях, у тому числі під час програмного пошуку записів. За замовчуванням порядок не вказано, тому записи будуть отримані в недетермінованому порядку залежно від PostgreSQL.

Атрибут _order приймає рядок, що містить список полів, які будуть використовуватися для сортування. Його буде перетворено на речення order_by у SQL. Наприклад:

from odoo import fields, models

class TestModel(models.Model):
    _name = "test_model"
    _description = "Test Model"
    _order = "id desc"

    description = fields.Char()

Наші записи впорядковані за спаданням id, тобто найвищий іде першим.

Exercise

Додати послідовність моделі.

Визначте такі замовлення у відповідних моделях:

Модель	Порядок
estate.property	ID за спаданням
estate.property.offer	Ціна за спаданням
estate.property.tag	Назва
estate.property.type	Назва

Представлення

Можливе замовлення на рівні моделі. Це має перевагу узгодженого порядку скрізь, де витягується список записів. Однак також можна визначити певний порядок безпосередньо в поданні завдяки атрибуту default_order (приклад).

Вручну

Упорядкування як моделі, так і перегляду забезпечує гнучкість під час сортування записів, але все ще є один випадок, який ми маємо розглянути: упорядкування вручну. Користувач може захотіти сортувати записи залежно від бізнес-логіки. Наприклад, у нашому модулі нерухомості ми хотіли б відсортувати типи власності вручну. Дійсно корисно, щоб типи, які найчастіше використовуються, відображалися у верхній частині списку. Якщо наше агентство нерухомості переважно продає будинки, то зручніше, щоб „Будинок“ стояв перед „Квартира“.

Для цього використовується поле sequence у поєднанні з віджетом handle. Очевидно, що поле sequence має бути першим полем в _order атрибуту.

Exercise

Додати послідовність вручну.

• Додайте таке поле:

Модель	Поле	Тип
estate.property.type	Послідовність	Integer

• Додайте послідовність до представлення списку estate.property.type з правильним віджетом.

Порада: ви можете знайти приклад тут: модель і представлення.

Атрибути та параметри

Було б непомірно детально описувати всі доступні функції, які дозволяють точно налаштувати вигляд паредставлення. Тому ми зупинимося на найпоширеніших.

Форма

Примітка

Ціль: наприкінці цього розділу вікно форми власності матиме:

• Умовне відображення кнопок і полів

• Кольори тегів

У нашому модулі нерухомості ми хочемо змінити поведінку деяких полів. Наприклад, ми не хочемо мати можливість створювати або редагувати тип властивості з представлення форми. Натомість ми очікуємо, що типи будуть оброблені у відповідному меню. Ми також хочемо надати тегам колір. Щоб додати ці налаштування поведінки, ми можемо додати атрибут options до кількох віджетів полів.

Exercise

Додайте параметри віджета.

• Додайте відповідну опцію до поля property_type_id, щоб запобігти створенню та редагування типу властивості з представлення форми властивості. Перегляньте документацію віджетів Many2one для отримання додаткової інформації.

• Додайте таке поле:

Модель	Поле	Тип
estate.property.tag	Колір	Integer

Потім додайте відповідну опцію до поля tag_ids, щоб додати вибір кольору до тегів. Перегляньте документацію віджетів FieldMany2ManyTags для отримання додаткової інформації.

У Розділ 6: Нарешті, інтерфейс для гри з ми побачили, що зарезервовані поля використовувалися для певної поведінки. Наприклад, поле active використовується для автоматичного фільтрування неактивних записів. Ми також додали state як зарезервоване поле. Настав час ним скористатися! Поле state використовується в поєднанні з states атрибутом у поданні для умовного відображення кнопок.

Exercise

Додайте умовне відображення кнопок.

Використовуйте атрибут states, щоб відображати кнопки заголовка умовно, як показано в Цілі цього розділу (зверніть увагу, як кнопки „Продано“ та „Скасувати“ змінюються, коли змінюється стан).

Порада: не соромтеся шукати states= у XML-файлах Odoo для деяких прикладів.

Загалом, можна зробити поле invisible, readonly або required на основі значення інших полів завдяки атрибуту attrs. Зауважте, що invisible також можна застосувати до інших елементів ппедставлення, таких як button або group.

attrs - це словник із властивістю як ключ і доменом як значенням. Домен визначає умови, в яких властивість застосовується. Наприклад:

<form>
    <field name="description" attrs="{'invisible': [('is_partner', '=', False)]}"/>
    <field name="is_partner" invisible="1"/>
</form>

Це означає, що поле description невидиме, якщо is_partner має значення False. Важливо зауважити, що поле, яке використовується в attrs має бути присутнім у представленні. Якщо він не повинен відображатися користувачеві, ми можемо використати атрибут invisible, щоб приховати його.

Exercise

Використовуйте attrs.

• Зробіть зону саду та орієнтацію невидимими у представленні форми estate.property, якщо саду немає.

• Зробіть кнопки „Прийняти“ та „Відмовитись“ невидимими після встановлення стану пропозиції.

• Не дозволяйте додавати пропозицію, якщо стан власності – „Пропозиція прийнята“, „Продано“ або „Скасовано“. Для цього використовуйте readonly attrs.

Попередження

Використання (умовного) атрибута readonly у представленні може бути корисним для запобігання помилкам при введенні даних, але майте на увазі, що це не забезпечує жодного рівня безпеки! Перевірка на стороні сервера не виконується, тому завжди можна писати в поле за допомогою виклику RPC.

Список

Примітка

Ціль: наприкінці цього розділу представлення списку властивостей і пропозицій має бути кольоровим. Крім того, пропозиції та теги можна буде редагувати безпосередньо в списку, а дата доступності буде прихована за замовчуванням.

Коли модель має лише кілька полів, може бути корисно редагувати записи безпосередньо через список і не відкривати вікно форми. У прикладі з нерухомістю немає необхідності відкривати представлення форми, щоб додати пропозицію або створити новий тег. Цього можна досягти завдяки атрибуту editable.

Exercise

Зробити список доступним для редагування.

Зробити доступними для редагування представлення списку estate.property.offer і estate.property.tag.

З іншого боку, коли модель має багато полів, може виникнути спокуса додати забагато полів у представленні списку та зробити його незрозумілим. Альтернативний спосіб - додати поля, але за бажання зробити їх прихованими. Цього можна досягти завдяки атрибуту optional.

Exercise

Зробіть поле необов’язковим.

Зробіть поле date_availability у списку estate.property необов’язковим і прихованим за замовчуванням.

Нарешті, кольорові коди корисні для візуального підкреслення записів. Наприклад, у модулі нерухомості ми хотіли б відображати відхилені пропозиції червоним кольором, а прийняті – зеленим. Цього можна досягти завдяки атрибуту decoration-{$name} (повний список див. Віджети поля):

<tree decoration-success="is_partner==True">
    <field name="name">
    <field name="is_partner" invisible="1">
</tree>

Записи, де is_partner має значення True, відображатимуться зеленим кольором.

Exercise

Додайте трохи декораторів.

У представленні списку estate.property:

• Об’єкти нерухомості з отриманою пропозицією виділені зеленим кольором

• Власності, пропозицію прийнято, виділено зеленим і жирним шрифтом

• Об’єкти, що продаються, ігноруються

У представленні списку estate.property.offer:

• Відмовлені пропозиції червоні

• Прийняті пропозиції зелені

• Стани більше не повинно бути видно

Поради:

• Майте на увазі, що всі поля, які використовуються в атрибутах, мають бути в представленні!

• Якщо ви хочете перевірити колір станів «Пропозицію отримано» та «Пропозицію прийнято», додайте поле в представлення форми та змініть його вручну (ми реалізуємо бізнес-логіку для цього пізніше).

Пошук

Посилання: документацію, пов’язану з цим розділом, можна знайти в Пошук і Пошук за умовчанням.

Примітка

Ціль: наприкінці цього розділу доступні властивості будуть відфільтровані за замовчуванням, а пошук у житловій площі повертає результати, де площа перевищує вказане число.

Нарешті, але не менш важливо, є деякі налаштування, які ми хотіли б застосувати під час пошуку. Перш за все, ми хочемо, щоб фільтр „Доступний“ застосовувався за замовчуванням під час доступу до властивостей. Щоб це сталося, нам потрібно використати контекст дії search_default_{$name}, де {$name} є назвою фільтра. Це означає, що ми можемо визначити, які фільтри будуть активовані за замовчуванням на рівні дії.

Ось приклад дії з її відповідним фільтром.

Exercise

Додайте фільтр за замовчуванням.

Зробіть фільтр „Доступний“ вибраним за замовчуванням у дії estate.property.

Ще одним корисним удосконаленням у нашому модулі стане можливість ефективного пошуку за площею проживання. На практиці користувач захоче шукати властивості „принаймні“ заданої області. Нереалістично очікувати, що користувачі захочуть знайти об’єкт нерухомості точної житлової площі. Завжди можна зробити індивідуальний пошук, але це незручно.

Елементи представлення пошуку <field> можуть мати filter_domain, який замінює домен, створений для пошуку в заданому полі. У вказаному домені self представляє значення, введене користувачем. У наведеному нижче прикладі він використовується для пошуку як у полях name, так і description.

<search string="Test">
    <field name="description" string="Name and description"
           filter_domain="['|', ('name', 'ilike', self), ('description', 'ilike', self)]"/>
    </group>
</search>

Exercise

Змінити пошук житлової площі.

Додайте filter_domain до житлової області, щоб включити властивості, площа яких дорівнює заданому значенню або перевищує його.

Кнопки статистики

Примітка

Ціль: у кінці цього розділу буде кнопка статистичних даних у представленні форми типу власності, яка показує список усіх пропозицій, пов’язаних із властивостями даного типу, коли її натиснути.

Якщо ви вже використовували деякі функціональні модулі в Odoo, ви, ймовірно, вже стикалися з „кнопкою статистики“. Ці кнопки відображаються у верхньому правому куті представлення форми та забезпечують швидкий доступ до пов’язаних документів. У нашому модулі нерухомості ми хотіли б мати швидке посилання на пропозиції, пов’язані з певним типом нерухомості, як зазначено в Цілі цього розділу.

На цьому етапі підручника ми вже бачили більшість концепцій для цього. Однак єдиного рішення немає, і це все одно може заплутати, якщо ви не знаєте, з чого почати. Ми опишемо покрокове рішення у вправі. Завжди може бути корисно знайти деякі приклади в кодовій базі Odoo, шукаючи oe_stat_button.

Наступна вправа може бути дещо складнішою за попередні, оскільки передбачається, що ви можете самостійно шукати приклади у вихідному коді. Якщо ви застрягли, можливо, поруч є хтось, хто може вам допомогти ;-)

Ця вправа знайомить із поняттям Пов’язані поля. Найпростіший спосіб зрозуміти це - розглядати його як окремий випадок обчислюваного поля. Наступне визначення поля description:

...

partner_id = fields.Many2one("res.partner", string="Partner")
description = fields.Char(related="partner_id.name")

еквівалентно:

...

partner_id = fields.Many2one("res.partner", string="Partner")
description = fields.Char(compute="_compute_description")

@api.depends("partner_id.name")
def _compute_description(self):
    for record in self:
        record.description = record.partner_id.name

Кожного разу, коли ім’я партнера змінюється, опис змінюється.

Exercise

Додайте кнопку статистики до типу властивості.

• Додайте поле property_type_id до estate.property.offer. Ми можемо визначити його як пов’язане поле в property_id.property_type_id і встановити його як збережене.

Завдяки цьому полю пропозиція буде пов’язана з типом нерухомості під час її створення. Ви можете додати поле до списку пропозицій, щоб переконатися, що воно працює.

• Додайте поле offer_ids до estate.property.type, яке є інверсією One2many до поля, визначеного на попередньому кроці.

• Додайте поле offer_count до estate.property.type. Це обчислене поле, яке підраховує кількість пропозицій для певного типу власності (для цього використовуйте offer_ids).

На даний момент у вас є вся необхідна інформація, щоб знати, скільки пропозицій пов’язано з типом нерухомості. Якщо сумніваєтеся, додайте offer_ids і offer_count безпосередньо до представлення. Наступним кроком буде відображення списку після натискання кнопки статистики.

• Створіть кнопку статистики на estate.property.type, яка вказує на дію estate.property.offer. Це означає, що вам слід використовувати атрибут type="action" (поверніться до кінця Розділ 10: Готові до дій?, якщо вам потрібно оновити інформацію).

На цьому етапі натискання кнопки статистики має відобразити всі пропозиції. Нам ще потрібно відфільтрувати пропозиції.

• У дії estate.property.offer додайте домен, який визначає property_type_id як рівний active_id (= поточний запис, ось приклад)

Виглядає гарно? Якщо ні, не хвилюйтеся, для наступного розділу кнопки статистики не потрібні ;-)