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:
- 17.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 !
If you have a code error (a.k.a. traceback), do include it in your bug report using code marks (not a screenshot!).
```
Traceback (most recent call last):
...
```
If you are reporting some client-side failure and you include client-side logs, you must enable the developer mode with assets before you paste the logs:
- Go to
Settings > Activate the developer mode (with assets).
Otherwise, your logs would come from the compressed version of the ECMAScript (a.k.a. JavaScript) sources, which means they would be completely useless.
- 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)
- If not done already, sign the CLA in your PR
- Do not use Pull Requests to update translations, this is done using an external system
- 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
- Write a test to reproduce the issue if possible. Not mandatory in all cases but it will speedup the review if needed.
| What | 15.0 | 16.0 | 17.0 | 18.0 | master |
|---|---|---|---|---|---|
| Bug fix | ❌ | ✓ | ✓ | ✓ | ❌ |
| Localizations | ❌ | ✓ | ✓ | ✓ | ✓ |
| Unstable change/Feature Request | ❌ | ❌ | ❌ | ❌ | ✓ |
Important: Please do NOT create pull requests with the same patch on multiple target branches. Fixes made in LTS versions (currently 16.0, 17.0, 18.0) will be forward ported to upper versions.
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), as they are part of the public API used by integrated systems
- No change in the signature of private methods as much as possible, as they can be overridden in extension modules, which will easily break when the signature changes.
- 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
noupdatemode initially. - 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.
- Critical security fixes must not depend on an explicit module update to take effect, they must work with a simple pull + restart
- Introducing new source terms (error messages, mail templates, view elements, etc.) should be reflected in the source terms of the module as explained here
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 handled on Transifex. See Translations page for details.
In stable versions:
- You MUST NOT modify existing terms (even to fix a typo) as it would break existing translations for people fetching the new source code.
- You MAY add or delete existing terms but then MUST modify the related
.potfile. Adding new terms is however NOT RECOMMENDED as may bring inconsistencies before being translated.
Corrections of the source terms should only be done in master version. If you want to correct a message in stable version (e.g. correct a typo), you can create a English -> English translation.
New releases will have a stabilization period of a couple of month when modifications of source terms is tolerated.
Odoo documentation is managed on a dedicated repository. Please report issues and suggest improvements related to the documentation there.
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 13.0-my-branch odoo/13.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
- Framework: PR or issue assigned to the javascript framework team (web client)
- ORM: PR or issue assigned to the python framework team (ORM)
- Accounting: PR or issue assigned to the accounting team
- Logistics: PR or issue assigned to the logistic team (warehouse management, MRP, PoS, procurment..)
- Website: PR or issue assigned to the website team (all website_* modules)
- Internationalization: PR or issue about translating Odoo correctly
- Localization: PR or issue about adapting Odoo to local rules (mainly the chart of accounts)
- Services: PR or issue assigned to the services team (project, timesheet, planning, ...)
- Marketing: PR or issue assigned to the marketing team (mass_mailing, elearning, crm, ...)
- Sales: PR or issue related to the Sales team (sale, subscription, payment, sign)
- Human Resources: PR or issue related to the HR team (hr_*, lunch, ...)
- web_editor: PR or issue for the drag&drop website editor
- RFC: Reserved label for Odoo asking feedback, usually for localization
- Packaging: PR or issue regarding packaged distributions of Odoo (.deb, .rpm, .exe, ...)
- Security: Reserved label for security announcements
- RD: Internal pull request, by Odoo R&D team.
- OE: PR created to solve an Odoo enterprise ticket
- CI: PR passed the runbot tests
- r+: PR positively reviewed by an acknoweledged Odoo employee, will be merged soon if build is green
Odoo uses BrowserStack for cross-browser integration tests.