Contributing

Adrian Torres edited this page Oct 31, 2018 · 70 revisions

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 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:
 
 - 11.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 !

Tracebacks

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:

  • In Odoo >= 10.0: Go to Settings > Activate the developer mode (with assets).
  • In Odoo < 10.0: Click on your user menu (top right corner) > About > Activate the developer mode.

Otherwise, your logs would come from the compressed version of the ECMAScript (a.k.a. JavaScript) sources, which means they would be completely useless.

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. Explain why you are doing a change, not what (should be understandable from the diff)
  7. Do not use Pull Requests to update translations, this is done using an external system
  8. Minimal commits! Rebase and squash your changes whenever you modify your PR and before submitting
  9. No conflicts! Rebase off the target branch just before submitting
  10. After Runbot verifies your PR, fix anything that breaks the tests

Against which version should I submit a patch?

What 9.0 10.0 11.0 12.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 10.0, 11.0, 12.0) will be forward ported to later versions periodically.

Here is how you see/change the target branch for your PR: Submitting against the right version

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.
  • 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 handled on Transifex. See Translations page for details.

How should I handle translatable content?

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 .pot file. 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.

How can I improve the documentation?

There is two documentations for Odoo. The Technical and the Functional documentation. Both are written in reStructuredText and open to contributions.

The technical is stored inside the doc folder and the user documentation is on a different repository odoo/documentation-user.

To correct or improve the documentation, simply create a pull request with your changes on the appropriate repository.

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 11.0-my-branch odoo/11.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
  • RD: Internal pull request, work in progress (by Odoo R&D team)
  • OE: pull request created to solve an Odoo enterprise ticket
  • Framework: PR or issue assigned to the framework team (ORM and web client)
  • Accounting: PR or issue assigned to the accounting team (account_, l10n_)
  • Logistic: 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 (most of the other modules)
  • 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

Credits

BrowserStack Logo

Odoo uses BrowserStack for cross-browser integration tests.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.