• Файл манифеста

Edit on GitHub

Файл манифеста

Файл манифеста служит для объявления пакета python в качестве модуля Odoo и для указания метаданных модуля.

Это файл под названием __manifest__.py, содержащий единственный словарь Python, где каждый ключ определяет метаданные модуля.

{
    'name': "A Module",
    'version': '1.0',
    'depends': ['base'],
    'author': "Author Name",
    'category': 'Category',
    'description': """
    Description text
    """,
    # data files always loaded at installation
    'data': [
        'views/mymodule_view.xml',
    ],
    # data files containing optionally loaded demonstration data
    'demo': [
        'demo/demo_data.xml',
    ],
}

Доступные поля манифеста:

name (str, обязательное)

удобочитаемое имя модуля

version (str)

Версия этого модуля должна соответствовать правилам semantic versioning

description (str)

Расширенное описание модуля, в формате reStructuredText

author (str)

Имя автора модуля

website (str)

URL веб-сайта автора модуля

license (str, по умолчанию: LGPL-3)

Лицензия на распространение для модуля

category (str, по умолчанию: Uncategorized)

Категория классификации в Odoo, примерная область применения модуля.

Рекомендуется использовать existing categories. Если введена произвольная категория, которой не существует, она создастся «на лету». Иерархия категорий может быть создана с использованием разделителя /, например Foo / Bar создаст категорию Foo, категорию Bar в качестве дочерней категории Foo, и установит Bar, как категорию модуля.

depends (list(str))

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

Когда модуль установлен, все его зависимости устанавливаются перед ним. Аналогично, зависимости загружаются до загрузки модуля.

data (list(str))

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

demo (list(str))

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

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

Если значение True, этот модуль будет автоматически установлен, если все его зависимости установлены.

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

Например, sale_crm зависит от sale и crm и имеет значение auto_install. Когда установлены как sale, так и crm, он автоматически добавляет к заказам на продажу отслеживание кампаний CRM.

external_dependencies (dict(key=list(str)))

A dictionary containing python and/or binary dependencies.

For python dependencies, the python key must be defined for this dictionary and a list of python modules to be imported should be assigned to it.

For binary dependencies, the bin key must be defined for this dictionary and a list of binary executable names should be assigned to it.

The module won't be installed if either the python module is not installed in the host machine or the binary executable is not found within the host machine's PATH environment variable.

application (bool, default: False)

Whether the module should be considered as a fully-fledged application (True) or is just a technical module (False) that provides some extra functionality to an existing application module.

css (list(str))

Specify css files with custom rules to be imported, these files should be located in static/src/css inside the module.

images (list(str))

Specify image files to be used by the module.

installable (bool default: False)

Whether a user should be able to install the module from the Web UI or not.

maintainer (str)

Person or entity in charge of the maintenance of this module, by default it is assumed that the author is the maintainer.

{pre_init, post_init, uninstall}_hook (str)

Hooks for module installation/uninstallation, their value should be a string representing the name of a function defined inside the module's __init__.py.

pre_init_hook takes a cursor as its only argument, this function is executed prior to the module's installation.

post_init_hook takes a cursor and a registry as its arguments, this function is executed right after the module's installation.

uninstall_hook takes a cursor and a registry as its arguments, this function is executed after the module's uninstallation.

These hooks should only be used when setup/cleanup required for this module is either extremely difficult or impossible through the api.