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

See the new Odoo user documentation.

See the new Odoo technical documentation.

Developing modules


Here you will find information about the organisation of the community in OpenERP project. It includes a description of the different tools used, the role of the different actors, and the different process for improvement management.

The whole organisation is managed through our launchpad projects: Our projects on launchpad are currently organised like this:

Project name




the main super-project (group) where all bugs, features and faq are managed


business intelligence project


the openobject server


the openobject application client (gtk)


the openobject web client (previously called eTiny)


the project for all modules about openobject


packaging around openobject (a selection of modules to build applications)

Getting Sources

Please refer to How to get the latest trunk source code in the Bazaar section

If you don't know the Bazaar version control system, please read the documentation on Bazaar

Coding Guidelines

Development Guidelines


Organisation of files in modules

The structure of a module should be:

Naming Objects and fields

Each object defined in your module must have at least one security rule defined on it to make it accessible.


Coding Guidelines

Follow Python PEP 8:


General Style
  • use the Helvetica font everywhere

  • margins (in millimeters):

    • top: 14

    • bottom: 16

    • left: between 12 and 13 to allow punching holes without punching in the text area

    • right: between 12 and 13


    the line separator between the header and the body can overlap slightly in the left and right margins: up to 9 millimeters on the left and up to 12 millimeters on the right

  • for Titles use font Helvetica-Bold with size 14.5

  • put the context on each report: example, for the report account_balance: the context is the fiscal year and periods

  • for the name of cells: use Capital Letter if the name contains more than one word (ex: Date Ordered)

  • content and name of cells should have the same indentation

  • for report, we can define two kinds of arrays:

    • array with general information, like reference, date..., use:

      • Bold-Helvetica and size=8 for cells name

      • Helvetica size="8" for content

    • array with detailed information, use:

      • Helvetica-Bold size 9 for cells names

      • Helvetica size 8 for content

Headers and footers for internal reports:
  • Internal report = all accounting reports and other that have only internal use (not sent to customers)

  • height of headers should be shorter

  • take off corporate header and footer for internal report (Use a simplified header for internal reports: Company's name, report title, printing date and page number)

  • header:

    • company's name: in the middle of each page

    • report's name: is printed centered after the header

    • printing date: not in the middle of the report, but on the left in the header

    • page number: on each page, is printed on the right. This page number should contain the current page number and the total of pages. Ex: page 3/15

  • footer:

    • to avoid wasting paper, we have taken off the footer

table line separator:
  • it's prettier if each line in a table has a light grey line as separator

  • use a grey column separator only for array containing general information

table breaking
  • a table header should at least have two data rows (no table header alone at the bottom of the page)

  • when a big table is broken, the table header is repeated on every page

how to differentiate parents and children ?
  • When you have more than one level, use these styles:

  • for the levels 1 and 2:fontSize="8.0" fontName="Helvetica-Bold"

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

  • underline sums when the element is a parent


Naming Convention

The name of the module are all lowercase, each word separated by underscores. Always start with the most relevant words, which are preferably names of other modules on which it depends.


  • account_invoice_layout

Information Required

Each module must contain at least:

  • name

  • description

Modules Description


Each module must contain:

  • A list of dependencies amongst others modules: ['account','sale']

    • Provide only highest requirement level, not need to set ['account','base','product','sale']

  • A version requirement string where base is the OpenERP version as a Python expression

    • account>=1.0 && base=4.4

Module Content

Each module must contain demo data for every object defined in the module.

If you implemented workflows in the module, create demo data that passes most branches of your workflow. You can use the module recorder to help you build such demo data.

User Interface Guidelines


Objects with States
  • The state field, if any, must be at the bottom left corner of the view

  • Buttons to make the state change at the right of this state field

Search Criteria

Search criteria: search available on all columns of the list view

Action Names



Default Language

The default language for every development must be U.S. English.

For menus and fields, use uppercase for all first letters, excluding conjections:

  • Chart of Accounts

Field Naming Conventions

  • Avoid generic terms in fields and use if possible explicit terms, some example:

    • Name -> Sale Order Name

    • Parent -> Bill of Material Parent

    • Rate -> Currency Rate Conversion

    • Amount -> Quantity Sold

Here are some rules to respect:

  • many2one fields should respect this regex: '.*_id'

  • one2many fields should respect this regex: '.*_ids'

  • one2many relation table should respect this regex: '.*_rel'

  • many2many fields should respect this regex: '.*_ids'

  • use underscore to separate words

  • avoid using uppercase

  • if a field is composed of several words, start with the most important words

    • This is good: sale_price, partner_address_id

    • This is bad: is_sellable

Object Naming Conventions

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

  • If an object is composed of several words, use points to separate words

Some terms

  • All Tree of resources are called XXX's Structure, unless a dedicated term exist for the concept

    • Good: Location' Structure, Chart of Accounts, Categories' Structure

    • Bad: Tree of Category, Tree of Bill of Materials

Module Recorder

Review quality

  • You can check your module quality using "base_module_quality" module available on stable addons