Contributing

Reporting Issues

1. Make sure you've actually read the error message if there is one, it may really help
2. No need to create an issue if you're making a PR to fix it. Describe the issue in the PR, it's the same as an issue, but with higher priority!
3. Double-check that the issue still occurs with the latest version of Odoo (you can easily test this on Runbot)
4. Search for similar issues before reporting anything
5. If you're not sure it's a bug, search in Odoo Help or ask a question there to find out
6. If you're a programmer, try investigating/fixing yourself, and consider making a Pull Request instead
7. If you really think a new issue is useful, keep in mind that it will be treated with a much lower priority than a Pull Request or an Odoo Enterprise support ticket

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

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

**Quantity field is ignored in a sale order**

Impacted versions:
 
 - 8.0
 
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.

Making Pull Requests

1. Make sure you have signed the CLA
2. Make sure you target the right branch
3. Keep your changes minimal, and strictly related to your issue (make other PRs if needed)
4. Match the style of the surrounding code, in terms of whitespace, wrapping, etc.
5. There are restrictions on the kind of changes allowed in stable series
6. Do not use Pull Requests to update translations, this is done using an external system (See our GitHub Transition page for details)
7. Minimal commits! Rebase and squash your changes whenever you modify your PR and before submitting
8. No conflicts! Rebase off the target branch just before submitting
9. After Runbot verifies your PR, fix anything that breaks the tests

Against which version should I submit a patch?

Fixes made in supported versions (currently 7.0, 8.0 + the last saas-x branch) will be forward ported to later versions periodically. No need to create a pull request for master if there is one for 8.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 8.0) for:
  • bug fixes that do not violate the stable guidelines

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). For Odoo 7.0 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

How can I translate Odoo in my language?

The translations are managed on a different platform than GitHub and synchronised periodically. Do not create pull requests to change the translations.

The translations are currently still handled on Launchpad. See GitHub Transition page for details.

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 8.0-my-branch odoo/8.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 whether it will be integrated
• RDWIP: Internal pull request, work in progress (by Odoo R&D team)
• OE: pull request created to solve an Odoo enterprise ticket