The new

OpenERP

Навигация

Навигация

Оглавление

Versions

Download free E-books Start your free trial

This is the documentation for older versions of Odoo (formerly OpenERP).

See the new Odoo user documentation.

See the new Odoo technical documentation.

Разработка модулей

Введение

Здесь вы найдёте информацию об организации сообщества в проекте OpenERP. Она включает описание различных используемых инструментов, роли различных участников, и управлении различными процессами улучшения.

Вся организация управляется через проекты на launchpad: http://launchpad.net Наши проекты на launchpad в настоящий момент организованы примерно так:

Имя проекта

Ссылка

Описание

openobject

https://launchpad.net/openobject

основной супер-проект (группа) где все ошибки, функции и ЧаВо управляются

openobject-addons

https://launchpad.net/openobject-addons

the project for core OpenERP modules

openobject-server

https://launchpad.net/openobject-server

the OpenERP server

openerp-web

https://launchpad.net/openerp-web

the web client for OpenERP 6.1 and newer versions

openobject-client

https://launchpad.net/openobject-client

the native client (gtk) for OpenERP 6.1 and earlier

openobject-client-web

https://launchpad.net/openobject-client-web

the web client for OpenERP 6.0 and earlier versions

Получение исходного кода

Пожалуйста, обратитесь к Как получить последний исходный код главной ветви в разделе Bazaar.

Если вы не знакомы с системой контроля версий Bazaar, прочтите документацию по Bazaar

Community Addons

OpenERP modules developed by the community were historically published in a shared source code branch on Launchpad, nicknamed extra-addons: https://code.launchpad.net/~openerp-commiter/openobject-addons/trunk-extra-addons

As of 2012 and the release of OpenERP 6.1, this shared branch is being phased out, due to several downsides to this organization, such as:

  • difficult to enforce access control on the modules (commit right is all or nothing)

  • difficult to enforce quality (therefore impossible to rely on it for customer projects)

  • commit history mixes all modules

  • download/checkout of the branch requires to fetch all modules at once

A better organization was discussed on the OpenERP mailing-lists, with the following goals:

  • To get rid of the big extra-addons branch

  • To join efforts on the same topic in order to avoid too many modules for a same feature

  • To become more aware of the developments that have been done by others

  • To start working with merge proposal between us

  • To improve the quality of our code

The community modules have therefore been split into separate Launchpad project and their respective branches. When possible, existing ones were reused. All listed projects provide a short description of the kind of modules you can find/merge into.

The community welcomes everyone on board to join efforts! In order to add your own modules in the appropriate project, you should use merge proposals. Depending on the volume, some time might be needed at the beginning to review everything. So thank you all in advance for your patience during this transition period.

For all of these projects, the rules we expect you to adhere to and respect are:

  • No company-related prefix or suffix in the module names (like c2c-account-something);

  • Always make merge proposal for any bugfix or improvement so that everyone can take note of it and eventually ask for a different approach;

  • Nobody merge his/her own work into the branch. Another member of the team must do it. Exceptions may be accepted if the merge proposal has been strongly approved by the rest of the team;

  • If your module doesn’t fit into any of the available projects, or you found no related team, please post a request on the framework expert mailing list so that we can create a specific one for you;

  • When at least one of your modules has been approved in the branch, you may ask to be part of the team. If you are not part of the team, you can still contribute to the project through merge proposals;

  • Use the available teams (see Community Contributor Teams section) according to their topics (it means that you always need to attribute a new project to these teams, so as to avoid having hundreds of them).

Should you have any suggestions related to the above rules, please feel free to post them on the framework expert mailing list.

Community Projects

The list of the official community projects/topics can be found under this project group: https://launchpad.net/openobject, and is summarized below.

Some of them are waiting on their owner to bring some modifications so they can fit into other projects (changing team, series,...). Should you be one of these owners, please inform the others on the mailing-list when ready. If some refuse to open the projects to the community, it is always possibel to create another project.

Misc Guidelines

Модули

Файловая структура модулей

Структура модуля выглядит примерно так:

/module_name/
/module_name/__init__.py
/module_name/__openerp__.py
/module_name/i18n
/module_name/i18n/module_name.pot
/module_name/images/
/module_name/images/screenshot.png
/module_name/migrations
/module_name/module.py
/module_name/module_view.xml
/module_name/module_wizard.xml
/module_name/module_report.xml
/module_name/module_data.xml
/module_name/module_demo.xml
/module_name/module_security.xml
/module_name/wizard/
/module_name/wizard/__init__.py
/module_name/wizard/wizard_name.py
/module_name/wizard/wizard_name_view.xml
/module_name/wizard/wizard_name_workflow.xml
/module_name/report/
/module_name/report/__init__.py
/module_name/report/report_name.sxw
/module_name/report/report_name.rml
/module_name/report/report_name.py
/module_name/security
/module_name/security/ir.model.access.csv
/module_name/static/src/img/icon.png
/module_name/tests

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

Каждый определённый в вашем модулей объект должен иметь как минимум одно объявленное правило безопасности, чтобы он был доступен.

Руководство по программированию

Следуйте правилу Python PEP 8: http://www.python.org/dev/peps/pep-0008/

Отчёты

Общий стиль

  • Используйте везде шрифт Helvetica

  • Отступы (в миллиметрах):

    • сверху: 14

    • снизу: 16

    • слева: от 12 до 13, чтобы можно было сделать перфорацию не повреждая текст

    • справа: от 12 до 13

    Примечание

    линия-разделитель между заголовком и телом может слегка перекрывать левую и правую границы: до 9 миллиметров влево и до 12 миллиметров вправо.

  • для заголовков используйте шрифт Helvetica-Bold размером 14.5

  • в каждый отчёт включайте контекст: например, для отчёта account_balance контекстом будут учётный год и периоды

  • для обозначения ячеек: используйте Заглавные Буквы если название содержит больше одного слова (пр.: Date Ordered)

  • содержимое и название ячейки должны иметь одинаковый отступ

  • для отчётов можно определить два типа массивов:

    • массив с общей информацией, например основания, дата..., используйте:

      • шрифт Helvetica-Bold, размер 8 для названия ячейки

      • шрифт Helvetica, размер 8 для содержимого

    • массив с подробной информацией, используйте:

      • шрифт Helvetica-Bold, размер 9 для названия ячейки

      • шрифт Helvetica, размер 8 для содержимого

Headers and footers for internal reports:

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

  • Размер заголовка должен быть меньше

  • Измените корпоративные верхний и нижний колонтитул для внутренних отчётов. Используйте упрощённые колонтитулы для внутренних отчётов: Название организации, заголовок отчёта, дата печати и номер страницы.

  • Верхний колонтитул:

    • название организации: в середине каждой страницы

    • название отчёта: печатается в центре, после верхнего колонтитула

    • дата печати: не в середине отчёта, но слева в верхнем колонтитуле

    • номер страницы: справа, на каждой странице. Должен состоять из номера текущей страницы и общего числа страниц. Напр. страница 3/15

  • Нижний колонтитул:

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

table line separator:

  • лучше, когда каждая строка таблицы имеет светло-серую строку в качестве разделителя

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

table breaking

  • следом за заголовком таблицы должны находиться минимум две строки с данными (избегайте заголовков таблиц внизу страницы)

  • когда разбивается большая таблица, заголовок должен повторяться на каждой странице

how to differentiate parents and children ?

  • При использовании более одного уровня, используйте эти стили:

  • для уровней 1 и 2: кегль 8.0 шрифт "Helvetica-Bold"

  • from the third level, use:fontName="Helvetica" fontSize="8.0" and increase the indentation with 13 (pixels) for each level

  • подчёркивайте суммы, когда элемент является родительским

Модули

Соглашение об именовании

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

Technical manager

  • account_invoice_layout

Требуемая информация

Каждый модуль должен содержать:

  • название

  • описание

Описание модулей

Зависимости

Каждый модуль должен содержать:

  • Список зависимостей от других модулей: ['account','sale']

  • Указывайте только модуль верхнего уровня. Нет необходимости указывать так: ['account','base','product','sale']

Содержимое модуля

Каждый модуль должен содержать демонстрационные данные для каждого объекта, объявленного в модуле.

Если вы реализовывали рабочие процессы в модуле, создайте демонстрационные данные, которые отражают большую часть созданного рабочего процесса. Вы можете использовать модуль recorder и с его помощью создать эти демонстрационные данные.

Язык по-умолчанию

Основной язык для каждой разработки — Американский английский

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

  • План счетов

Соглашение об именовании полей

  • поля many2one (много-к-одному) должны подпадать под регулярное выражение: '.*_id'

  • поля one2many (один-ко-многим) должны подпадать под регулярное выражение: '.*_ids'

  • таблица отношений one2many (один-ко-многим) должна подпадать под регулярное выражение: '.*_rel'

  • поля many2many (многие-ко-многим) должны подпадать под регулярное выражение: '.*_ids'

  • для разделения слов используйте знак подчёркивания

  • избегайте использование верхнего регистра

  • если поле должно состоять из нескольких слов — начните с самых важных слов

Model Naming Conventions

  • All objects must start with the name of the module they are defined in.

  • Если название объекта состоит из нескольких слов — используйте точки для разделения слов.

Терминология

  • Все деревья ресурсов называются "Структура ХХХ", если только иное не оговорено отдельно

    • Правильно: Структура расположений, План счетов, Структура категорий

    • Неправильно: Дерево категорий, Дерево перечней материалов