Toggle navigation

Создание модуля - Odoo 8.0

Запуск и остановка сервера Odoo

Odoo использует клиент-серверную архитектуру, где клиентами являются web браузеры, которые работают с Odoo сервером через RPC протокол.

Бизнес-логика и расширение обычно выполняются на стороне сервера, хотя к клиенту могут быть добавлены поддерживающие клиентские функции (например, новые представления данных, такие как интерактивные карты).

Чтобы запустить сервер, просто вызовите команду odoo.py в командной строке, добавив при необходимости полный путь к файлу:

odoo.py

Сервер можно остановить двойным нажатием Ctrl-C в консоли, или убив соответствующий процесс в операционной системе.

Создание модуля в Odoo

Расширения как сервера, так и клиента представляют собой модули, которые могут быть загружены в базу данных.

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

Таким образом, все в Odoo начинается и заканчивается модулями.

Состав модуля

Модуль Odoo может содержать следующие элементы:

Бизнес-объекты:

объявленные как Python классы, эти ресурсы автоматически сохраняются в Odoo в соответствии с ее конфигурацией

Данные

XML или CSV файлы объявляют метаданные (представления или бизнес-процессы), данные конфигурации (параметризация модулей), демонстрацию данных и многое другое

Веб-контроллеры

Обрабатывать запросы от веб-браузеров

Статические ресурсы

Изображения, CSS или javascript-файлы, используемые веб-интерфейсом или веб-сайтом

Структура модуля

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

Содержимое Odoo модуля описывается в его манифесте. Подробное описание манифеста находится здесь.

Модуль так же является Python пакетом с файлом __init__.py, содержащим инструкции импорта для различных Python файлов в модуле.

Например, если в модуле есть только mymodule.py, тогда файл __init__.py должен содержать:

from . import mymodule

Odoo предоставляет механизм, который помогает установить новый модуль, odoo.py имеет команду scaffold, которая может создать пустой модуль:

$ odoo.py scaffold <module name> <where to put it>

Команда создаст подкаталог для вашего модуля, и автоматически создаст группу стандартных файлов для модуля. Большинство из них содержит закомментированный Python код или XML. Об использование большинства этих файлов будет рассказано в данном руководстве.

Объектно-реляционное отображение

Ключевой компонент Odoo это ORM. Этот слой избавляет от необходимости писать самому SQL запросы руками и предоставляет гибкие и безопасные сервисы 2.

Бизнес-объекты объявляются как расширяемые классы Python Model, которая автоматически интегрирует их в систему хранения данных.

Модели данных могут быть сконфигурированы настройкой некоторого количества атрибутов в их описании. Наиболее важный атрибут это _name. Он необходим и определяет название модели данных в системе Odoo. Вот пример минимального описания модели данных:

from openerp import models
class MinimalModel(models.Model):
    _name = 'test.model'

Поля модели данных

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

from openerp import models, fields

class LessMinimalModel(models.Model):
    _name = 'test.model2'

    name = fields.Char()

Базовые атрибуты

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

name = field.Char(required=True)

Некоторые атрибуты доступны во всех полях, вот самые распространенные из них:

string (unicode, по умолчанию: field's name)

Надпись для поля в UI (пользовательском интерфейсе).

required (bool, по умолчанию: False)

Если True, поле не может быть пустым оно должно иметь значение по умолчанию или всегда быть заполнено при создании записи.

help (unicode, по умолчанию: '')

Портянка, показывает всплывающее поле с описанием объекта для пользователей в UI.

index (bool, по умолчанию: False)

Просит у Odoo создать database index для колонки

Простые поля

Есть два наиболее распространенных вида полей: «простые» поля, которые представляют собой атомарные значения, хранящиеся непосредственно в таблице модели, и «реляционные» поля, связывающие записи (одной модели данных или разных моделей данных).

Пример простых полей Boolean, Date, Char.

Зарезервированные поля

Odoo создает несколько полей, которые есть во всех моделях данных1. Эти поля управляются системой и их не нужно прописывать, но их можно прочитать если существует такая необходимость:

id (Id)

уникальные идентификатор записи в этой модели данных

create_date (Datetime)

дата создания записи

create_uid (Many2one)

пользователь, который создал запись

write_date (Datetime)

дата последней модификации записи

write_uid (Many2one)

Пользователь, который последний модифицировал запись

Специальные поля

По умолчанию Odoo так же требует поле name для всех моделей данных для различных типов отображения и поиска. Поле, используемое для этих целей может быть отменено _rec_name.

Данные

Odoo - система со сверхточным механизмом управления данными. Несмотря на то что ее поведение управляется при помощи кода Python, часть значений модуля находится в данных, которые он устанавливает при загрузке.

Данные модуля описываются через data files, XML файлы с элементами <record>. Каждый элемент <record> создает или модифицирует записи в базе данных.

<openerp>
    <data>
        <record model="{model name}" id="{record identifier}">
            <field name="{a field name}">{a value}</field>
        </record>
    </data>
<openerp>

  • model это имя модели данных Odoo записи

  • id это external identifier, который позволяет видеть к какой записи эти данные относятся (без необходимости знать их идентификаторы в базе данных)

  • <field> элементы имеют параметр name который является именем поля в модели данных (например description). Тело элемента и есть значение поля.

Файлы данных должны быть описаны в файле манифеста, для того, чтобы они были загружены их нужно записать в 'data' список (загрузка данных происходит всегда) или в 'demo' список (загрузка данных происходит только в режиме "Загрузка демо-данных").

Действия и пункты меню

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

  1. нажатием на пункт меню (который связан с конкретным действием)

  2. нажатием на кнопки в формах представлений данных (если они связаны с конкретным действием)

  3. как контекстное действие над объектом

Поскольку пункты меню могут иметь сложную структуру для их описания есть параметр <menuitem> это наиболее простой способ создать описание меню в ir.ui.menu и подключить его к соответствующему действию.

<record model="ir.actions.act_window" id="action_list_ideas">
    <field name="name">Ideas</field>
    <field name="res_model">idea.idea</field>
    <field name="view_mode">tree,form</field>
</record>
<menuitem id="menu_ideas" parent="menu_root" name="Ideas" sequence="10"
          action="action_list_ideas"/>

Базовые представления данных

Базовые представления данных (далее представления). Представления определяют каким образом записи или модель данных будут отображены. Каждый тип представлений являет собой некий заранее оформленный внешний вид для данных, которые находятся в базе данных Odoo (например в виде списка записей или календаря, и т.д. …). Представления могут быть запрошены через вызов их типа (например список контрагентов) или напрямую через их идентификатор. Для общих запросов будет использовано представление с правильным типом и низким приоритетом (таким образом, представление с наименьшим приоритетом каждого типа, будет являться им по умолчанию

Наследование представлений позволяет изменять представления, объявленные в другом месте (добавлять или удалять содержимое).

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

Представление создается как запись модели данных `` ir.ui.view``. Тип преставления назначается корневым элементом поля arch:

<record model="ir.ui.view" id="view_id">
    <field name="name">view.name</field>
    <field name="model">object_name</field>
    <field name="priority" eval="16"/>
    <field name="arch" type="xml">
        <!-- view content: <form>, <tree>, <graph>, ... -->
    </field>
</record>

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

Преставления в виде Tree, так же называются преставлениями в виде списков, отражают записи в табличной форме

Их корневой элемент <tree>. Самая простая форма преставления в виде tree это список всех полей таблицы, которые мы хотим показать на экране (каждое поле это колонка):

<tree string="Idea list">
    <field name="name"/>
    <field name="inventor_id"/>
</tree>

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

Преставления в виде Form используются для создания и модификации единичных записей.

Корневым элементом является <form>, который состоит из высокоуровневых элементов (группы, поля для записей) и интерактивных элементов (кнопки и поля):

<form string="Idea form">
    <group colspan="4">
        <group colspan="2" col="2">
            <separator string="General stuff" colspan="2"/>
            <field name="name"/>
            <field name="inventor_id"/>
        </group>

        <group colspan="2" col="2">
            <separator string="Dates" colspan="2"/>
            <field name="active"/>
            <field name="invent_date" readonly="1"/>
        </group>

        <notebook colspan="4">
            <page string="Description">
                <field name="description" nolabel="1"/>
            </page>
        </notebook>

        <field name="state"/>
    </group>
</form>

Представления формы могут также использовать простой HTML для создания своих макетов:

<form string="Idea Form">
    <header>
        <button string="Confirm" type="object" name="action_confirm"
                states="draft" class="oe_highlight" />
        <button string="Mark as done" type="object" name="action_done"
                states="confirmed" class="oe_highlight"/>
        <button string="Reset to draft" type="object" name="action_draft"
                states="confirmed,done" />
        <field name="state" widget="statusbar"/>
    </header>
    <sheet>
        <div class="oe_title">
            <label for="name" class="oe_edit_only" string="Idea Name" />
            <h1><field name="name" /></h1>
        </div>
        <separator string="General" colspan="2" />
        <group colspan="2" col="2">
            <field name="description" placeholder="Idea description..." />
        </group>
    </sheet>
</form>

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

Преставления в виде Search настраивают поля search для связи с преставлением в виде списка (а так же другими совокупными представлениями). Их корневой элемент <search> и он состоит из полей определяющих какие поля могут участвовать в поиске:

<search>
    <field name="name"/>
    <field name="inventor_id"/>
</search>

Если для модели данных не существует поискового представления, Odoo генерирует одно, которое позволяет только поиск в поле `` name``.

Отношения между моделями данных

Запись из одной модели данных может быть связана с записью в другой модели данных. Например запись коммерческого предложения связана с записью клиента, которая содержит данные о клиента; и она (запись клиента) так же связана с записями коммерческого предложения.

Реляционные поля

Реляционные поля связывают записи, как внутри самой модели данных (иерархические), так и между записями в разных моделях данных.

Типы реляционных полей:

Many2one(other_model, ondelete='set null')

Простая ссылка на другой объект:

print foo.other_id.name
One2many(other_model, related_field)

Виртуальная связь обратная Many2one. Это One2many ведет себя как контейнер записей и предоставляет доступ (возможно пустой) к набору записей:

for other in foo.other_ids:
    print other.name
Many2many(other_model)

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

for other in foo.other_ids:
    print other.name

Наследование

Наследование моделей данных

Odoo предлагает механизм наследования в двух вариантах для расширения существующей модели данных путем создания дополнительного модуля

Первый механизм наследования позволяет модулю изменять поведение модели данных, определенной в другом модуле:

  • добавлять поля к модели данных

  • Переопределить определения полей в модели данных

  • Добавить ограничения в модель данных

  • Добавить методы в модель данных

  • Переопределить существующие методы в модели данных.

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

Наследование представления

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

Расширение представления соотносится со своим родителем, используя поле inherit_id, и во отличии от одиночного представления его поле arch состоит из любого количества элементов xpath, предоставляя возможность выбора альтернативного наполнения родительского представления:

<!-- improved idea categories list -->
<record id="idea_category_list2" model="ir.ui.view">
    <field name="name">id.category.list2</field>
    <field name="model">idea.category</field>
    <field name="inherit_id" ref="id_category_list"/>
    <field name="arch" type="xml">
        <!-- find field description and add the field
             idea_ids after it -->
        <xpath expr="//field[@name='description']" position="after">
          <field name="idea_ids" string="Number of ideas"/>
        </xpath>
    </field>
</record>
expr

Выражение XPath, выбирает определенный элемент родительского представления. Вызывает ошибку, если он не соответствует ни одному элементу или более одного.

position

Команда для применения к конкретному элементу:

inside

присоединяет тело внутри контейнера xpath после выбранного элемента

replace

заменяет выбранный элемент xpath контейнером

before

вставляет контейнер xpath, как неотъемлемую часть в начале выбранного элемента

after

вставляет контейнер xpaths, как неотъемлемую часть в конце выбранного элемента

attributes

предоставляет альтенативные атрибуты выбранного элемента используя специальную команду attribute внутри контейнера xpath

Домены

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

К примеру, при использовании в модели данных Product домен выбирает все services цена которых выше 1000 за одну позицию:

[('product_type', '=', 'service'), ('unit_price', '>', 1000)]

По умолчанию, критерии тесно взаимосвязаны с безусловным AND. Логические операторы & (AND), | (OR) и ! (NOT) могут использоваться для явного объединения критериев. Они используются в позиции префикса (оператор вставляется перед своими аргументами, а не между ними). Например, чтобы выбрать продукты "которые являются услугами ИЛИ имеют цену за единицу, которая НЕ попадает между 1000 и 2000":

['|',
    ('product_type', '=', 'service'),
    '!', '&',
        ('unit_price', '>=', 1000),
        ('unit_price', '<', 2000)]

Параметр domain может быть добавлен к зависимым полям, с целью отделения действительных записей для работы, в процессе выбора записей в базе для работы с клиентским интерфейсом.

Вычисляемые поля и значения по умолчанию

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

Для создания вычисляемого поля вам нужно создать поле, установив атрибут compute в его метод. Метод вычисления должен просто устанавливать значение поля в вычисляемое в любой записи self.

import random
from openerp import models, fields

class ComputedModel(models.Model):
    _name = 'test.computed'

    name = fields.Char(compute='_compute_name')

    @api.multi
    def _compute_name(self):
        for record in self:
            record.name = str(random.randint(1, 1e6))

Зависимости

Значение вычисленного поля обычно зависит от значений других полей в вычисляемой записи. ORM подразумевает, что разработчик укажет эти зависимости для метода compute с помощью декоратора depends(). Данные зависимости используются ORM для инициирования перерасчета поля при изменении некоторых его зависимостей:

from openerp import models, fields, api

class ComputedModel(models.Model):
    _name = 'test.computed'

    name = fields.Char(compute='_compute_name')
    value = fields.Integer()

    @api.depends('value')
    def _compute_name(self):
        for record in self:
            self.name = "Record with value %s" % self.value

Значения по умолчанию

Любому полю может быть присвоено значение по умолчанию. В определении поля добавьте опцию default=X, где X является либо литеральным значением Python (логическое, целочисленное, float, string), либо функцией, берущей набор записей и возвращающей значение:

name = fields.Char(default="Unknown")
user_id = fields.Many2one('res.users', default=lambda self: self.env.user)

Onchange

Механизм «onchange» предоставляет возможность для клиентского интерфейса обновлять форму, когда пользователь заполняет значение в поле, не сохраняя ничего в базе данных.

Например, предположим, что модель имеет три поля amount, unit_price и price, и вы хотите обновить цену в форме, когда какие-либо другие поля изменены. Для этого определите метод, в котором self представляет запись в виде формы, и обозначьте его при помощи функции onchange(), чтобы указать, в каком поле она должна быть запущена. Любые изменения, внесенные вами в self, будут отражены в форме.

<!-- content of form view -->
<field name="amount"/>
<field name="unit_price"/>
<field name="price" readonly="1"/>

# onchange handler
@api.onchange('amount', 'unit_price')
def _onchange_price(self):
    # set auto-changing field
    self.price = self.amount * self.unit_price
    # Can optionally return a warning and domains
    return {
        'warning': {
            'title': "Something bad happened",
            'message': "It was very bad indeed",
        }
    }

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

Ограничения модели данных

Odoo предоставляет два способа настройки автоматической проверки инвариантов: Python constraints и SQL constraints.

Ограничение Python определяется как метод с декоратором constrains(), и вызывается в наборе записей. Декоратор определяет, какие поля участвуют в ограничении, так что ограничение автоматически оценивается, когда одно из этих полей изменяется. Подразумевается, что метод вернет ошибку, если его инвариант не выполняется:

from openerp.exceptions import ValidationError

@api.constrains('age')
def _check_something(self):
    for record in self:
        if record.age > 20:
            raise ValidationError("Your record is too old: %s" % record.age)
    # all records passed the test, don't return anything

Ограничения SQL определяются с помощью атрибута модели данных _sql_constraints. Последнему присваивается список троек из строк (name, sql_definition, message), где name является допустимым именем ограничения SQL, sql_definition является выражением table_constraint и message - сообщением об ошибке.

Расширенные представления

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

Представления вида Tree могут принимать дополнительные атрибуты для дальнейшей настройки их поведения:

colors

Сопоставление цветов с условиями. Если условие оценивается как `` True``, соответствующий цвет применяется к строке:

<tree string="Idea Categories" colors="blue:state=='draft';red:state=='trashed'">
    <field name="name"/>
    <field name="state"/>
</tree>

Разделы разделяются символом ;, цвет и условие разделяются символом :.

editable

"top" или "bottom". Делает представления вида Tree доступным для редактирования в самих строках (вместо того, чтобы просматривать форму), значение - это позиция, где появляются новые строки.

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

Отображает записи, как события календаря. Их корневым элементом является <calendar>, а их наиболее распространенными атрибутами являются:

color

Имя поля, используемое для сегментации цветом. Цвета автоматически распределяются по событиям. События в одном цветовом сегменте (записи, имеющие одинаковое значение для их поля @color) будут иметь одинаковый цвет.

date_start

Поле записи, содержащее дату/время начала события

date_stop (опционально)

Поле записи, содержащее конечную дату/время события

Поле (для определения метки для каждого события в календаре)

<calendar string="Ideas" date_start="invent_date" color="inventor_id">
    <field name="name"/>
</calendar>

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

Элементы <field> представления вида Search могут иметь filter_domain, который переопределяет домен, сгенерированный для поиска по данному полю. В данной области self представляет собой значение, введенное пользователем. В приведенном ниже примере он используется для поиска по обоим полям name и``description``.

Представление вида Search также могут содержать элементы <filter>, которые действуют как кнопки предопределенных поисков. Фильтры должны иметь один из следующих атрибутов:

domain

Добавит данный домен в текущий поиск

context

Добавит некоторый контекст в текущий поиск; Используйте ключ group_by для группировки результатов по данному имени поля

<search string="Ideas">
    <field name="name"/>
    <field name="description" string="Name and description"
           filter_domain="['|', ('name', 'ilike', self), ('description', 'ilike', self)]"/>
    <field name="inventor_id"/>
    <field name="country_id" widget="selection"/>

    <filter name="my_ideas" string="My Ideas"
            domain="[('inventor_id', '=', uid)]"/>
    <group string="Group By">
        <filter name="group_by_inventor" string="Inventor"
                context="{'group_by': 'inventor_id'}"/>
    </group>
</search>

Чтобы использовать в действии нестандартное представление вида Search, нужно указать связь, используя поле search_view_id в записи действия.

Действие также может устанавливать значения по умолчанию для полей поиска через поле context: контекстные ключи формы search_default_field_name будут инициализировать field_name с предоставленным значением. Чтобы иметь значение по умолчанию и вести себя как логические значения (их можно включить только по умолчанию), в фильтре поиска должно быть определено необязательное @name.

Представление вида Gantt

Горизонтальные гистограммы, которые обычно используются для отображения планирования и продвижения проекта, их корневым элементом является <gantt>.

<gantt string="Ideas" date_start="invent_date" color="inventor_id">
    <level object="idea.idea" link="id" domain="[]">
        <field name="inventor_id"/>
    </level>
</gantt>

Представление вида Graph

Представления вида Graph позволяют делать сборный обзор и анализ моделей данных, их корневым элементом является <graph>.

Представления вида Graph имеют 4 режима отображения, режим по умолчанию выбирается с помощью атрибута @type.

Pivot

Многомерная таблица, позволяет выбирать фильтры и измерения, чтобы получить правильный агрегированный набор данных, прежде чем перейти к более графическому обзору

Bar (по умолчанию)

Гистограмма, первое измерение используется для определения групп по горизонтальной оси, другие измерения определяют агрегированные бары внутри каждой группы.

По умолчанию столбцы расположены бок о бок, они могут быть сложены с помощью @stacked="True" на <graph>

Line

2-мерная линейная диаграмма

Pie

2-мерный круговая диаграмма, разделенная на сектора

Представления вида Graph содержат <field> с обязательным атрибутом @type, принимающим значения:

row (по умолчанию)

Поле по умолчанию, в отношении которого будет совершен сбор данных

measure

объединяет значения величин всех дочерних объектов, игнорируя их группы

<graph string="Total idea score by Inventor">
    <field name="inventor_id"/>
    <field name="score" type="measure"/>
</graph>

Представление вида Kanban

Используется для организации задач, производственных процессов и т.д ... их корневым элементом является <kanban>.

Представление вида Kanban показывает набор карточек, которые могут быть сгруппированы в столбцы. Каждая карточка представляет собой запись, а в каждом столбце - значения поля состояния.

Например, задачи проекта могут быть организованы поэтапно (каждый столбец - это этап) или ответственным (каждый столбец является пользователем) и т.д.

Представления вида Kanban определяют структуру каждой карточки, как сочетание элементов формы (включая базовый HTML) и Qweb.

Бизнес-процессы

Бизнес-процессы - это модели данных, связанные с бизнес-объектами, описывающими их динамику. Бизнес-процессы также используются для отслеживания состояния процессов, которые изменяются с течением времени.

Бизнес-процессы могут быть связаны с любым объектом в Odoo и настроены по вашему желанию. Бизнес-процессы используются для структурирования и управления жизненными циклами бизнес-объектов и документов, а также определения переходов, триггеров и т.д. с помощью графических инструментов. Бизнес-процессы, активности (узлы или действия) и транзакции (условия) объявляются как XML-записи. Токены, которые перемещаются в бизнес-процессах, называются workitems.

Безопасность

Чтобы политика безопасности была согласована (без противоречий), необходимо правильно настроить контроль доступа.

Контроль доступа, основанный на группах пользователей

Группы создаются как записи модели данных res.groups, и предоставляют доступ к меню через определение меню (в соответствующем XML файле). Однако даже без меню объекты могут все еще быть доступны косвенно, поэтому для групп должны быть определены разрешения на уровне объекта (чтение, запись, создание, отключение). Они обычно вставляются через CSV-файлы внутри модулей. Также можно ограничить доступ к определенным полям для представления или объекта, используя атрибут групп полей.

Права доступа

Права доступа определяются, как записи в `` ir.model.access``. каждое правило связано с определенной моделью данных, группой (или же no group для глобальных ресурсов), а также набором разрешений: чтение, запись, создание, отключение. Обычно, такие правила заданы в файле CSV, названном по имени модели данных: ir.model.access.csv.

id,name,model_id/id,group_id/id,perm_read,perm_write,perm_create,perm_unlink
access_idea_idea,idea.idea,model_idea_idea,base.group_user,1,1,1,0
access_idea_vote,idea.vote,model_idea_vote,base.group_user,1,1,1,0

Правила записи

Права записи определяют ограничения доступа к списку записей конкретной модели данных. Правило представляет собой запись модели данных ir.rule и связано с моделью данных, группами (поле many2many), разрешениями, к которым применяется ограничение, а также с domain. Domain указывает, к каким записям права доступа ограничены.

Ниже приведен пример правила, которое предотвращает удаление записей, в котором не указан атрибут cancel. Обратите внимание, что значение поля groups должно соответствовать тому же соглашению, что и метод write() в ORM.

<record id="delete_cancelled_only" model="ir.rule">
    <field name="name">Only cancelled leads may be deleted</field>
    <field name="model_id" ref="crm.model_crm_lead"/>
    <field name="groups" eval="[(4, ref('base.group_sale_manager'))]"/>
    <field name="perm_read" eval="0"/>
    <field name="perm_write" eval="0"/>
    <field name="perm_create" eval="0"/>
    <field name="perm_unlink" eval="1" />
    <field name="domain_force">[('state','=','cancel')]</field>
</record>

Помощники

Помощники описывают интерактивную работу с пользователями через динамические формы. Мастер - это модель данных, которая расширяет класс: TransientModel вместо Model. Класс TransientModel расширяет Model и повторно использует все его существующие механизмы со следующими особенностями:

  • Записи мастера не являются постоянными; Они автоматически удаляются из базы данных через определенное время. Вот почему они называются transient (транзитные).

  • Модели помощников не нуждаются в явных объявлениях прав доступа: пользователи имеют все права доступа к записям помощников.

  • Записи мастера могут относиться как к обычным записям, так и к записям полей many2one, а регулярные записи не могут ссылаться на записи мастера через поле many2one.

Мы хотим создать помощника, который позволит пользователям становиться участниками определенного Курса или списка Курсов одновременно.

Запуск помощников

Запустить помощника можно через ir.actions.act_window, указав в поле target значение new. Последний открывает окно помощника в новом всплывающем окне. Действие может быть вызвано пунктом меню.

Также, существует и другой вариант запуска: Используйте код ir.actions.act_window, как указано выше, но, добавив туда еще одну инструкцию src_model, определяющую, в контексте какой модели действие будет доступно. Помощник появится строго при определенных условиях, расположившись поверх основного окна. В данном случае, через ORM, все это прописывается в файле XML с тэгом act_window.

<act_window id="launch_the_wizard"
            name="Launch the Wizard"
            src_model="context_model_name"
            res_model="wizard_model_name"
            view_mode="form"
            target="new"
            key2="client_action_multi"/>

Помощник использует стандартное представление, а его кнопки могут снабжаться атрибутом special = "cancel ", чтобы закрыть окно помощника без сохранения.

Переводы

Каждый модуль может иметь несколько вариантов перевода. Все они находятся в папке i18n в виде LANG.po файлов, где LANG - код локали для языка, или же, комбинация Язык_Страна, в случае, если они отличаются (пример: pt.po или pt_BR.po). Перевод будет автоматически втянут в Odoo для всех отмеченных языков. Разработчики используют английский для создания модулей, затем экспортируют термины модуля в Odoo's через gettext POT export (Settings ‣ Translations ‣ Import/Export ‣ Export Translation без указания языка), создавая пустой шаблон POT, добавляя затем еще и файлы переводов PO. Множество IDE's снабжены специальными инструментами для работы с файлами PO/POT.

|- idea/ # The module directory
   |- i18n/ # Translation files
      | - idea.pot # Translation Template (exported from Odoo)
      | - fr.po # French translation
      | - pt_BR.po # Brazilian Portuguese translation
      | (...)

Отчеты

Отчеты для печати

В Odoo 8.0 встроен новый движок для ведения документации, базирующийся на Qweb, Twitter Bootstrap и Wkhtmltopdf.

Отчет представляет собой комбинацию двух элементов:

  • an ir.actions.report.xml, где <report> shortcut element is provided, it sets up various basic parameters for the report (defaulявляется ярлыком, устанавливающим различные параметры для отчета (тип по умолчанию, необходимость сохранения отчета в базе после его генерации,…)

    <report
    id="account_invoices"
    model="account.invoice"
    string="Invoices"
    report_type="qweb-pdf"
    name="account.report_invoice"
    file="account.report_invoice"
    attachment_use="True"
    attachment="(object.state in ('open','paid')) and
        ('INV'+(object.number or '').replace('/','')+'.pdf')"
/>

  • Стандартный вид QWeb view для отчета:

    <t t-call="report.html_container">
    <t t-foreach="docs" t-as="o">
        <t t-call="report.external_layout">
            <div class="page">
                <h2>Report title</h2>
            </div>
        </t>
    </t>
</t>

the standard rendering context provides a number of elements, the most
important being:

``docs``
    the records for which the report is printed
``user``
    the user printing the report

Поскольку отчеты являются стандартными веб-страницами, они доступны через URL, а выходные параметры могут обрабатываться по этому URL-адресу, например, HTML-версия отчета Invoice доступна через http://localhost:8069/report/html/account.report_invoice/1 (если установлен модуль ​​``account``) и версия PDF через http://localhost:8069/report/pdf/account.report_invoice/1.

Сводные отчеты

Веб сервисы

Модуль веб-сервиса предлагает общий интерфейс для всех веб-сервисов

  • XML-RPC
  • JSON-RPC

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

Odoo доступна через интерфейсы XML-RPC/JSON-RPC, для которых библиотеки существуют на многих языках.

Библиотека XML-RPC

В данном примере отражено взаимодействие программы на Python с библиотекой xmlrpclib:

import xmlrpclib

root = 'http://%s:%d/xmlrpc/' % (HOST, PORT)

uid = xmlrpclib.ServerProxy(root + 'common').login(DB, USER, PASS)
print "Logged in as %s (uid: %d)" % (USER, uid)

# Create a new note
sock = xmlrpclib.ServerProxy(root + 'object')
args = {
    'color' : 8,
    'memo' : 'This is a note',
    'create_uid': uid,
}
note_id = sock.execute(DB, uid, PASS, 'note.note', 'create', args)

Библиотека JSON-RPC

В следующем примера программа на Python взаимодействует с сервером Odoo при помощи стандартных библиотек Python urllib2 и json:

import json
import random
import urllib2

def json_rpc(url, method, params):
    data = {
        "jsonrpc": "2.0",
        "method": method,
        "params": params,
        "id": random.randint(0, 1000000000),
    }
    req = urllib2.Request(url=url, data=json.dumps(data), headers={
        "Content-Type":"application/json",
    })
    reply = json.load(urllib2.urlopen(req))
    if reply.get("error"):
        raise Exception(reply["error"])
    return reply["result"]

def call(url, service, method, *args):
    return json_rpc(url, "call", {"service": service, "method": method, "args": args})

# log in the given database
url = "http://%s:%s/jsonrpc" % (HOST, PORT)
uid = call(url, "common", "login", DB, USER, PASS)

# create a new note
args = {
    'color' : 8,
    'memo' : 'This is another note',
    'create_uid': uid,
}
note_id = call(url, "object", "execute", DB, uid, PASS, 'note.note', 'create', args)

А вот та же программа, использующая jsonrpclib:

import jsonrpclib

# server proxy object
url = "http://%s:%s/jsonrpc" % (HOST, PORT)
server = jsonrpclib.Server(url)

# log in the given database
uid = server.call(service="common", method="login", args=[DB, USER, PASS])

# helper function for invoking model methods
def invoke(model, method, *args):
    args = [DB, uid, PASS, model, method] + list(args)
    return server.call(service="object", method="execute", args=args)

# create a new note
args = {
    'color' : 8,
    'memo' : 'This is another note',
    'create_uid': uid,
}
note_id = invoke('note.note', 'create', args)

Примеры могут быть легко адаптированы из XML-RPC в JSON-RPC.

[2]

Запись прямых SQL-запросов возможна, но требует осторожности, поскольку обходит все механизмы аутентификации и безопасности Odoo.