Contributing

Reporting Issues

If possible, always attach a pull request when creating an issue (GitHub will automatically create an issue when submitting the changes). The issues not linked to a pull request or an internal request on odoo.com will be handled with a lower priority.

If later on you create a pull request solving an opened issue, do not forget to reference to it in your pull request (e.g.: "This patch fixes issue #42").

When reporting an issue or creating a pull request, use the following structure:

Quantity field is ignored in a sale order

Impacted versions:

• 7.0 and above

Steps to reproduce:

1. create a new sale order
2. add a line with product 'Service', quantity 2, unit price 10.0
3. validate the sale order

Current behavior:

• Total price of 10.0

Expected behavior:

• Total price of 20.0 (2 * 10 = 20)

For web or rendering issues, do not forget to specify the operating system and browser you are using.

Against which version should I submit a patch?

Fixes made in supported versions (currently 7.0 + the last saas-x branch) will be forward ported to master periodically. No need to create a pull request for master if there is one for 7.0, for example.

• odoo/master for:
  • changes in the API (method signature or return format)
  • changes requiring an update of the database (e.g. new fields)
  • new features
• odoo/X.0 (last stable version, currently 7.0) for:
  • correction of bugs that do not violate the stable guidelines (see below)

What does "Stable" mean?

Changes in stable series must respect these guidelines:

• Keep changes to a minimum: stable patches must have a good value/risk ratio. If risk is too high or value too low, it must not be merged at all in stable (rather in the development series)
• No "improvement" (technical or functional) should be done in stable, they typically have a very low value/risk ratio. Often, the functional coverage is voluntarily limited.
• No purely cosmetic changes (formatting, pep8, etc.)
• No change in the signature of public methods on model (methods not starting with an underscore)
• No data model change: stored columns definitions must not be altered in incompatible manners under any circumstances (no addition / removal / incompatible type change)
• Limited, compatible changes such as changing ondelete rules or size parameters are allowed when necessary.
• For non-compatible change, in extreme cases an extra auto-install module could be added in order to automatically patch new installations without breaking existing ones
• No change to the XML IDs of existing module data, and no deletion of module data records that may be referenced by user data in existing databases, unless the changes are absolutely essential and the records were in "noupdate" mode initially.
• No change in the structure of workflows (new/relocated activities/transitions) unless the change is 100% safe for existing records and does not break anything with or without update.
• Non-stored function fields may be added if it is really necessary. XML files (views, menus, default data, etc.) should only be changed if inevitable. When changed, the change must not be mandatory, i.e. the Python code must not depend on the change.
• It is fine if a bugfix requires an explicit update, as long as it is safe for users who are not aware of it and do not perform the update.
• A bugfix must not require updating the source code of 2 different modules at the same time, (or server and addons at the same time). As of v7 the embedded 1-click update system may selectively update modules (including base) without re-downloading the source of all modules.
• Critical security fixes must not depend on an explicit module update to take effect, they must work with a simple pull + restart

Why was my issue closed without merging?

A pull request is closed when it will not be merged into odoo. This will typically happens if the fix/issue:

• is not relevant to odoo development (label invalid)
• is not considered as a bug or we have no plan to change the current behavior (label wontfix)
• is a duplicate of another opened issue (label duplicate)
• the pull request should be resubmitted against another version

What is this odoo-dev repository? Should I use it?

The odoo-dev/odoo repository is an internal repository used by the R&D of Odoo to keep the main repository clean. If you are coming from Launchpad, this is the equivalent of the ~openerp-dev repository.

When forking odoo to submit a patch, always use the github.com/odoo/odoo repository. Be also careful of the version you are branching as it will determine the history once the pull request will be realized (e.g.: git checkout -b 7.0-my-branch odoo/7.0).

Meaning of labels

• blocked: a fix or information from the author of the request is required before merging
• confirmed: issue was validated by qualification team
• need review: a second level of review is required
• wishlist: new feature, to discuss if will be integrated
• RDWIP: Internal pull request, work in progress (by odoo SA RD team)
• OE: pull request created to solve an odoo enterprise ticket