- 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 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 a Vauxoo 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:
- 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)
The main idea is to create a little how-to commit by commit to know how to improve this modules in a clean way and help us to help you, then if you are including your new concepts try to be explicit and helpful in your commit messages.
-
Clone this repository:
$ git clone [email protected]:vauxoo/addons-vauxoo.git -b 17.0 $ cd addons-vauxoo $ git remote add your-name [email protected]:your-github-name/addons-vauxoo.git # << to push your changes
-
Before declaring this repository as part of your addons-path: Install all external dependencies. note: You will need some non-standar packages (npm and lessc to be precise) when you have v17.0 installed.
-
Create your own branch locally.
$ git checkout -b 17.0-your_new_feature_theme-your-name
-
Push your first change branch to know you start to work on.
$ git push -u origin 17.0-your_new_feature_theme-your-name
-
Prepare your environment to work with this repository and the mandatory ones to have all the environment ready.
$ git clone https://github.com/odoo/odoo.git -b 17.0 $ git clone https://github.com/vauxoo/addons-vauxoo.git -b 17.0
-
Create a postgres user (only for this work to avoid problems not related to this environment).
$ sudo su postgres $ createuser testuser -P ##### put your password just the number one (1) for example. $ createdb test -U testuser -O testuser -T template0 -E UTF8
-
Run the development environment.
$ cd path/to/odoo/odoo $ ./odoo-bin \ --addons-path=addons/,../addons-vauxoo -r \ testuser -w 1 --db-filter=test \ -i module_to_improve -d test
-
Do your code, code, code, code and update it passing -u module -d test (replacing this parameter above).
-
Before you need to be sure all is ok, we can delete and create db again with -i parameter to ensure all install correctly.
$ sudo su postgres $ dropbd test $ createdb test -U testuser -O testuser -T template0 -E UTF8 $ ./odoo-bin \ --addons-path=addons/,../addonstest-vauxoo,../server-tools -r \ testuser -w 1 --db-filter=test \ -i module_to_improve -d test
-
If all is ok installing, please test your environment running your code with ?test-enabled?.
$ ./odoo-bin --addons-path=addons/,../addons-vauxoo,../test -r \ testuser -w 1 --db-filter=test \ -i module_to_improve-d test --test-enable
Note:
This will take a time, just do it before commiting your changes and make push.
-
Add your changes to have them versioned.
$ git add .
-
Commit your changes.
$ git commit -m "[TAG] module: what you did"
-
Push your first change branch to know you start to work on.
$ git push -u your-name 15.0-your_new_feature_theme-your-name
-
Make a PR with your changes as you usually do it with github's web interface or using hub.
- Descriptions.
- Descriptions of modules can be on a README.md, README.rst, avoid put the descriptions directly on the descriptor openerp.py file, the best way to do something new is using a README.md file in some moment all our modules will be on that way.
- Dependencies.
- Try to avoid imports of external libraries without a try, except to manage a WARNING controlling the external error, if is mandatory such need.
- Module Structure.
- The structure of all internal odoo stuff try to follow the rules under OCA, and remember always do what we say and not what we do ;-) if you find things that do not comply such rules, it can be considered a bug, please share with us what you find and Pull Requests are welcome.
- Naming convention.
- All modules must start with the name of meta functional area which they will
work with, i.e:
account_*
,website_*
,sale_*
. - The module should not contain names not precises like
*_extra
or*_extension
if your module do whatever call it whatever.
- All modules must start with the name of meta functional area which they will
work with, i.e:
- Reasons because a module can be here.
- The feature is generic.
- The module can work standalone or combined with other modules here or in OCA.
- Feature is planned to be maintained in future versions, very specific features which are specific for a user case on a customer can not be here.
- Coding
- Python: We try to follow pep8 and check with pylint all our Pull requests, to verify this locally just read the .travis file and replicate such verification locally.
- XML and HTML We try to have 4 space for indentation, avoid the tabs, and try to have all initial tag declaration in one line except for reports declaration which can be in one line per attribute, this is not verified by any lint checker but it is good if you help us there.