Contributing
- Make sure you've actually read the error message if there is one, it may really help
- 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!
- Double-check that the issue still occurs with the latest version of Odoo (you can easily test this on Runbot)
- Search for similar issues before reporting anything
- If you're not sure it's a bug, search in Odoo Help or ask a question there to find out
- If you're a programmer, try investigating/fixing yourself, and consider making a Pull Request instead
- 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 you think you need to report a security vulnerability, please see our Responsible Disclosure page. Our security issues archive can be found here.
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:
- 9.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.
When appropriate please provide screenshots and/or screencast demonstrating the issue.
Don't forget that a bug obvious to you may not be to others (maybe not using the same modules, etc.), don't neglect reproducing conditions !
- Make sure you have signed the CLA
- Make sure you target the right branch
- Keep your changes minimal, and strictly related to your issue (make other PRs if needed)
- Match the style of the surrounding code, in terms of whitespace, wrapping, etc.
- There are restrictions on the kind of changes allowed in stable series
- Explain why you are doing a change, not what (should be understandable from the diff)
- Do not use Pull Requests to update translations, this is done using an external system (See our GitHub Transition page for details)
- Minimal commits! Rebase and squash your changes whenever you modify your PR and before submitting
- No conflicts! Rebase off the target branch just before submitting
- After Runbot verifies your PR, fix anything that breaks the tests
| What | 7.0 | 8.0 | 9.0 | master |
|---|---|---|---|---|
| Bug fix | ✓ | ✓ | ✓ | ❌ |
| Localizations | ✓ | ✓ | ✓ | ✓ |
| Payment providers | ❌ | ✓ | ✓ | ✓ |
| Shipping providers | ❌ | ❌ | ✓ | ✓ |
| Unstable changes | ❌ | ❌ | ❌ | ✓ |
Important: Please do NOT create pull requests with the same patch on multiple target branches. Fixes made in LTS versions (currently 7.0, 8.0, 9.0) will be forward ported to later versions periodically.
Here is how you see/change the target branch for your PR:
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
ondeleterules orsizeparameters 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.
- Critical security fixes must not depend on an explicit module update to take effect, they must work with a simple pull + restart
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.
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
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).
- 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
- RD: Internal pull request, work in progress (by Odoo R&D team)
- OE: pull request created to solve an Odoo enterprise ticket
Odoo uses BrowserStack for cross-browser integration tests.