Візуалізація даних на інф. панелях¶

Важливо

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

Термін «Інф. панель» використовується в Odoo для об’єктів, які відображають дані, але передбачає різні реалізації. У цьому посібнику буде зосереджено лише перегляд Enterprise, який використовується для візуалізації зведених даних. Їх можна додати як view_mode до існуючої моделі (тобто перегляду, на який можна переключитися за допомогою кнопок перегляду у верхньому правому куті представленні), але вони також часто використовуються як представлення для спеціальної моделі налаштований для візуалізації даних. Ви можете почути, що ці спеціальні представлення називаються представленнями SQL.

Корисно зазначити, що в спільноті Odoo є додаток «Інф. панель». Цей додаток дозволяє користувачам створювати власний налаштований перегляд даних, але налаштування бачать лише кожен користувач і можуть переглядатися лише в додатку «Інф. панель». Технічно можливо створити глобальні інф. панелі за допомогою цього модуля board, але це набагато простіше зробити у вигляді Enterprise. Крім того, він виглядає привабливіше та має додаткові функції, недоступні у board. Деякі інші інф. панелі в Odoo також існують, але вони створені на замовлення й виходять за рамки цього посібника.

Документацію щодо цієї теми можна знайти в Інф. панелm.

Структура файлу¶

Ви, мабуть, уже здогадалися, що оскільки представлення інф. панелі є представленням Enterprise, вони повинні мати залежність від модуля Enterprise. Модуль Enterprise – це web_dashboard. Не забудьте додати його до файлу маніфесту! Стандартно додавати інф. панелі, призначені для використання як view_mode для однієї з моделей вашого модуля (у папці model) до каталогу представлень (тобто той самий файл, який містить інші представлення для того самого модель).

Стандартним є створення окремого Enterprise модуля для додавання додаткових Enterprise представлень і функцій до Community модуля. Це робиться подібно до методики зв’язування модулів, описаної в Розділ 14: Взаємодія з іншими модулями. Різниця полягає в тому, що замість того, щоб зв’язувати 2 різні модулі, ми розширюємо наш модуль estate. Ми робимо це, створюючи новий модуль і додаючи до його маніфесту як модуль Community, так і його необхідні залежності модуля Enterprise. Ви зазвичай побачите «»enterprise» в назві каталогу модуля. Щоб цей підручник був простим, ми додамо інф. панелі до нашого існуючого модуля estate.

Представлення SQL мають 2 частини: файл xml (не забудьте додати його до файлу маніфесту) і файл Python (не забудьте додати його до відповідних файлів __init.py__). Перший має той самий формат, що й xml view_mode, а другий містить спеціальну модель і код SQL для заповнення його полів. Стандартно додавати файли представлення SQL до каталогу report/. Також часто включати «report» в назві файлів представлення SQL. Вам може бути цікаво, чому ми розміщуємо файли в каталозі звітів? Раніше ми бачили, що інф. панель призначена для візуалізації даних, тому її не можна редагувати. Інф. панелі можна розглядати як інтерактивні звіти, у яких можна клацати статистичні дані, графіки та діаграми, щоб переглянути конкретні дані, які в них вносяться. Зауважте, що також стандартно зберігати код xml для шаблони звітів PDF у каталозі звітів.

Очікується, що ваше робоче дерево виглядатиме приблизно так:

estate
├── models
│   ├── *.py
│   └── __init__.py
├── report
│   ├── __init__.py
│   ├── estate_report.py
│   └── estate_report_views.xml
├── security
│   └── ir.model.access.csv
├── views
│   ├── *.xml
│   └── estate_property_views.xml
├── __init__.py
└── __manifest__.py

Представлення інф. панелі¶

Примітка

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

Інф. панелі можуть відображати дані різними способами, зокрема:

показує aggregate поля
використання агрегованих полів у formula
за допомогою widget
використовуючи інший view як підпредставлення

Є багато корисних статистичних і візуальних матеріалів, які ми можемо надати для нашого прикладу нерухомості, використовуючи ці параметри. Повний приклад, на який можна посилатися під час виконання вправ у цьому розділі, можна переглянути тут <https://github.com/odoo/enterprise/blob/6fd3244ae168dc73c348a9c1870796e89d8ef594/crm_enterprise/views/crm_lead_views.xml#L106-L133>`__ (знову обмежений github посилання на репозиторій).

Дані¶

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

Принаймні 3 нерухомості з різними типами нерухомості, очікуваними цінами та середньою житловою площею.
Принаймні 1 продана нерухомість і принаймні 1 анульована нерухомість

Якщо у вас ще немає такого набору даних, ви можете:

Заповніть Визначення даних модуля (якщо ви цього ще не зробили) і додайте додаткові кейси до ваших демонстраційних даних (можливо, вам доведеться створити нову базу даних для завантаження в демонстраційні дані).
Вручну створіть дані у своїй базі даних.
Скопіюйте цей файл даних у нову директорію з назвою data у вашому модулі estate і скопіюйте ці рядки у ваш файл __manifest__.py (вам може знадобитися створити нову базу даних для завантаження демонстраційних даних).

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

Агрегації¶

Створення представлення інф. панелі дуже схоже на те, що ви робили раніше в Розділ 7: Основні представлення. Для представлення інф. панелі ми використовуємо кореневий елемент dashboard і вибираємо з його можливих тегів (дивіться всі можливості та їх атрибути в документації Інф. панелm). Ось простий приклад інф. панелі:

<dashboard>
    <group>
        <aggregate name="min_expected_price" string="Min Expected Price" field="expected_price"
            group_operator="min" help="Lowest expected price."/>
    </group>
</dashboard>

У цьому прикладі <group>` додає стиль, а ``<aggregate> оголошує агрегацію. Ми вказуємо, яке field ми хочемо об’єднати, який string виводити зі значенням і як його об’єднати за допомогою атрибута group_operator. Атрибут group_operator може використовувати будь-яку допустиму функцію агрегації PostgreSQL, а також спеціальну функцію count_distinct, визначену Odoo.

Сподіваємося, ви пам’ятаєте, як додавати представлення до віконної дії view_mode (підказка, це описано у Розділ 6: Нарешті, інтерфейс для гри з). Тепер давайте зробимо кілька інф. панелей!

Exercise

Зробіть представлення інф. панелі.

Створіть інф. панель агрегованих значень для моделі estate.property. Для натхнення ви можете подивитися на Мета цього розділу. Не забудьте перевірити, що ваша статистика обчислюється так, як ви очікуєте, і зверніть увагу, що обчислені значення враховують будь-які застосовані фільтри представлення!
Бонус: додайте деякі агрегації, які потребують domain, щоб мати сенс (пам’ятайте, що про домени також йшлося в Розділ 7: Основні представлення).

Pie Charts¶

Додавання секторних діаграм до інф. панелей - простіше простого за допомогою елемента <widget>. Ось приклад:

<dashboard>
    <group>
      <widget name="pie_chart" title="Property Types" attrs="{'groupby': 'property_type_id'}"/>
    </group>
</dashboard>

У цьому прикладі ми вказуємо, що використовуємо віджет pie_chart з атрибутом name і заголовком title для кругової діаграми, і що ми групуємо її за типом властивості.

Exercise

Додайте кілька круглих діаграм.

Додайте кругові діаграми з Ціль цього розділу на вашу інф. панель. Підказка: вам потрібно буде додати 'measure': selling_price до вашої кругової діаграми attrs, якщо ви хочете показати ціни продажу, згруповані за типом нерухомості.
Наведіть курсор і клацніть на секторні діаграми, щоб перевірити значення підрахунків, і не забувайте, що фільтри також будуть застосовані до діаграм.
Бонус: додайте домен на кругову діаграму ціни продажу, щоб вона включала тільки «sold» об’єкти (тобто без об’єктів «offer_accepted»). Зверніть увагу, що символ ' потрібно екранувати, оскільки він оголошений як частина attrs.

Підпредставлення¶

Подібно до того, як ми можемо використовувати представлення списку в представленні форми (ми побачили, що це автоматично відбувається для зв’язків One2many у Розділ 8: Зв’язки між моделями), ми можемо додавати інші представлення на нашу інф. панель. Найчастіше додаються зведені та графіки, але когортне представлення також є опцією. Інф. панель лише з підпредставленням:

<dashboard>
    <view type="graph"/>
    <view type="pivot"/>
</dashboard>

Атрибут ref можна додати до елементів <view> для використання певного XML id для цього представлення. Якщо для графіка чи зведеного представлення не надано XML id, буде використано подання за замовчуванням. Представлення когорти не працюватиме на інф. панелі без певного XML id. Якщо ви вже створили деякі з цих представлень, ви можете додати їх на свою інф. панель! Зразок графіка та зведені представлення включені в код рішення, який ви також можете використовувати.

Exercise

Додати підпредставлення.

Додайте графік і зведене представлення на інф. панель. Спробуйте пограти з макетом своїх вкладених представлень у зв’язку з круговими діаграмами та зведеними значеннями та зверніться до Цілі цього розділу, щоб дізнатися про часто використовуваний макет. Не забудьте перевірити, чи ваші вкладені представлення відображають дані належним чином (і так, на них також впливають фільтри!).

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

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

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

Примітка

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

Іноді ми хочемо показати дані, які виходять за межі того, що вже є в нашій моделі. Ми можемо додати багато збережених обчислюваних або пов’язаних полів (незбережені поля не можна агрегувати або відображати на кругових діаграмах), але було б непрактично зберігати купу полів тільки для цієї мети. Замість цього ми можемо додати власне SQL-представлення, щоб мінімізувати обчислювальне навантаження і зберегти нашу модель чистою від непотрібних полів.

Модель¶

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

from odoo import fields, models, tools


class EstateReport(models.Model):
    _name = 'estate.report'
    _description = "Stock Report"
    _rec_name = 'id'
    _auto = False

_auto = False вказує на те, що ми не хочемо зберігати модель в базі даних і створимо кастомну таблицю, перевизначивши метод BaseModel.init(). _rec_name вказує, яке з полів моделі представляє назву запису (тобто назва, яка буде використовуватися в навігації при відкритті форми запису). У цьому випадку я залишив значення „id“, оскільки наші пропозиції нерухомості не мають назви. Пізніше нам знадобиться імпорт tools (тобто odoo/odoo/tools, який містить безліч корисних допоміжних методів, які ви, ймовірно, будете використовувати в майбутньому). Зауважте, що стандартом є додавання report до назви моделі.

Пам’ятайте, що вашу нову модель потрібно буде додати до файлу безпеки, як ви дізналися з Розділ 5: Безпека - короткий вступ!

Потім ми визначаємо поля, необхідні для нашої інф. панелі, так само, як і для будь-якої іншої моделі (як ви дізналися з Розділ 4: Моделі та базові поля), за винятком того, що кожне поле має значення readonly=True. Зрештою, наша модель призначена лише для читання.

Тепер ми перевизначимо метод BaseModel.init(), згаданий раніше:

def init(self):
    tools.drop_view_if_exists(self.env.cr, self._table)
    self.env.cr.execute("""CREATE or REPLACE VIEW %s as (
                           SELECT
                              %s
                           FROM
                              %s
          )""" % (self._table, self._select(), self._from()))

Ми використовуємо tools.drop_view_if_exists, щоб переконатися, що ми не створюємо конфліктуючих представлень, а потім виконуємо SQL-запит. Стандартним є розділення різних частин запиту для полегшення розширення моделі. Точний спосіб розділення запиту на методи не стандартизовано, але ви часто бачите як мінімум методи _select і _from [або щось подібне], і, звичайно, всі ці методи повертають рядки. Стовпці з SELECT заповнять поля нашої моделі, тому переконайтеся, що назви ваших стовпців відповідають назвам полів або використовуйте аліаси, які збігаються.

Exercise

Створіть модель звіту.

Створіть модель звіту з наступними полями:

Поле	Тип	Примітка
id	Integer	Відповідає `id` в `estate.property.offer`
offer_state	Selection	Дорівнює `state` вибору `estate.property.offer`
property_id	Many2one	`estate.property`
property_state	Selection	Дорівнює `state` вибору `estate.property`
property_type_id	Many2one	`estate.property.type`

і напишіть SQL-запит, необхідний для заповнення полів (підказка: вам знадобиться 2 JOIN).

Ви не зможете перевірити правильність вашої моделі, поки ми не створимо для неї подання, але ви можете перевірити ваш запит безпосередньо у вашій базі даних, щоб переконатися, що результати відповідають вашим очікуванням. Якщо у вас виникнуть труднощі з цією вправою, то ось приклад <https://github.com/odoo/odoo/blob/7417d8fc138b9de550bc631435bcc08628c29bed/addons/crm/report/crm_activity_report.py>`__ для ознайомлення.

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

Тепер, коли у нас є наша модель, ми можемо створити її представлення у вигляді інф. панелі. Немає ніякої різниці в тому, як це робиться, за винятком того, що його файл знаходиться в папці report. Оскільки це нова модель, не пов’язана з жодною іншою моделлю, нам також доведеться додати новий пункт меню для представлення нашої інф. панелі. Зазвичай, SQL представлення додаються в меню першого рівня, яке називається Звіти (тому що це звіт, сюрприз!). Ви пам’ятаєте, як додати меню? Якщо ні, перегляньте Розділ 6: Нарешті, інтерфейс для гри з ще раз.

Exercise

Створіть представлення звіту.

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

Додаткові поради¶

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

Але для таких випадків, як усереднені агрегації або використання підпредставлення, наприклад зведеного представлення, цю помилку легко пропустити. Також легко пропустити цю помилку, якщо у вас недостатньо тестових даних. Щоб додати до цього звіту кілька властивостей, скасованих за типом властивостей, кругової діаграми, нам доведеться або вдатися до хаку (занадто складно для цього підручника), або просто виключити його з цього звіту.

Порада 2 Якщо у вас є поле, яке ви не хочете використовувати як міру (наприклад, у зведеному або графічному представленні), ви можете додати до нього store=False, і воно не буде показано.

Edit on GitHub