This wiki page is intended to guide you through your first technical steps in your new job. You are about to begin a training course that should last 2-3 weeks (for R&D and Tech Support).

If you find a dead link, think of a possible improvement, or just want to give your feedback, feel free to do it here! It will help us improve the onboarding process of your future colleagues ;)

1. Order your lunch

If you want lunch, you can order it every day in the Lunch module, before 10.30 am.

Ask the office managers if you need help.

2. Setup your machine

Git

We use Git to manage Odoo sources. Our source code is hosted on GitHub (the website you're currently looking at).

Install Git on your computer if it's not already done. You can check if Git is installed by typing git --version in a terminal.
If you don't have a GitHub account, create one. The standard for the username is trigram-odoo but it could be anything you want. Give your username to your guru so that he can give you the accesses.
If you are not a Git Jedi Master yet, you can consult this very good tutorial. It is mandatory to know how to rewrite the history of commits. To visualize the effect of git commands on the commits graphs, play with this interactive tutorial.

Code editor

Any good code editor that gives you syntactic coloration, auto-completion... for Python, JavaScript, XML and CSS should do the trick. You are the maintainer of your machine, so choose an editor that fits your coding habits.

Here is a list of some we use:

To align more easily with the coding conventions of Python, JavaScript and XML, consider installing good linters. Linters are tools that statically analyse your code and point out any issues in it (brackets mismatch, syntax errors...). Often, code editors have plugins that integrate these linters (ask a colleague who has the same editor as you).

For Python, Flake8 gives good outputs.
For Javascript, JSHint rocks !
For XML, you can use xmllint if your editor doesn't provide built-in linting.

Odoo

Odoo code base is split into two repositories: community modules are located in the odoo repository along with the framework while the enterprise repository hosts modules exclusively accessible with an Enterprise license.

Follow this tutorial to install Odoo from source.

Remember that you need both the Community and Enterprise repositories to have a working Enterprise edition. This file structure will do the job (but is not mandatory):

/home/you/whatever
|-- odoo
|  |-- community  (odoo/odoo.git)
|  |-- enterprise (odoo/enterprise.git)

3. Technical training

Technical requirements

Below are the main technical requirements for developing in Odoo. You don't need to be an expert in each of them from day one but having a good understanding of how to work with them will surely help.

We recommend that you start immediately with the exercises to get a better idea of what is awaiting you. When you encounter an exercise with a new requirement, head to the section of that requirement that corresponds the best to your current skills.

Python

Odoo's backend currently runs on Python 3.6. If you have a more recent version of Python installed on your machine, no need to downgrade it but take care to stick to language features compatible with this version.

For reference, here is the official Python 3.6 tutorial.

Beginner

Pick the tutorial of your choice to discover the basics of Python. Take your time to feel confident with this language before moving to the next section as learning a new programming language on top of Odoo too fast may not go so well.

You can choose to read the documentation, follow a series of videos, challenge other programmers, learn with interactive tutorials, or whatever floats your boat.

This ranking will help you find the tutorial that best suits your needs. Just make sure to search for Python 3 and to follow a free course.
Codewars allows you to challenge other programmers and gives you feedback on your code.
The Hitchhiker's Guide will teach you the good practices of Python.

Intermediate

If you have good experience of similar languages or just need a quick recall, this guide is made for you.

Expert

Why are you even reading this ?

JavaScript

You should find a tutorial that suits your level in this "re-introduction" to JavaScript.

If you just need a quick recall, this one will do the trick.

(Postgre)SQL

If you are not familiar with PostgreSQL, these exercises, will teach you better than any long documentation.

Training exercises

Back-end training (Python)

This training is intended for people who want to develop modules with the Odoo framework and is hosted on Odoo slides. Each module introduces you to a different aspect of coding in Odoo in the form of an exercise to do by yourself. As modules are built on top of the previous ones, you can either expand your solution as you progress through the exercises or do any module independently. The course is based on a github repository.

It is a first approach, and it may take you some time to be familiar with it. Do not hesitate to ask questions to your guru or to your colleagues.

The slides advises the use of Odoo.sh. Do not use Odoo.sh to do your training. We recommended the use of Odoo.sh for partners taking a 3-day training, so they do not waste time on installing Odoo on their computer. However, as a developer at Odoo, you obviously must know how to install Odoo from sources.

Some solutions are available as a possible implementation for the related problem. Note that the suggested solution is only one of the many potential implementations.

Front-end training (Javascript)

Currently, the Javascript training begins here. If you are completely lost, just jump to the HEAD of the repository. The solutions are there. But do as you would do when you do a crossword puzzle: Go looking for solutions only when you are completely screwed.

Only do exercises part 1 & part 2.

This is the training for 13.0, and this is already outdated as we already changed the JS framework in master, and therefore the way to build javascript widgets. This is the reason why we ask only the first two exercises, so you do not spend too much time learning something already deprecated, but this is still useful to learn it anyway, in case you need to dig up 13.0 or 12.0 Odoo javascript widgets.

For information, the new JS framework in Odoo (currently in master, meaning for the next Odoo 14.0) is called "OWL": https://github.com/odoo/owl .

If you have the motivation, you can follow the OWL tutorials.

4. Setup your Odoo repositories for your first task

At Odoo, we work mainly with 4 Git repositories. The table below summarizes them:

	Dev (features branches & bugfixes)	Public
Community	`odoo-dev/odoo`	`odoo/odoo`
Enterprise	`odoo-dev/enterprise`	`odoo/enterprise`

Here is the common flow when you start working on a new task in R&D:

You create a new dev branch based on the stable branch that you target.
You push your commits on the odoo-dev repo corresponding to your changes.
Once your task is done and your commit history is clean, you create a pull request (PR) targeting the stable branch on the odoo repository.

To follow this process easily, take the time to configure your git repositories.

Warning: NEVER use git push --force (or git push -f) in a branch that does not belong to you nor in a stable branch. Never, never, never!

5. Final Notes

Task stages

We use our internal project management tool to manage development and support tasks. Here are the steps that a task should follow during its lifecycle. Search for RD Fun for R&D projects or Help if you are in tech support.

You can also take a look at the task guidelines.

Gurus

Gurus are the technical mentors in each team. They usually have good expertise of the apps in their team's scope. Don't hesitate to ask your guru if you are stuck on a technical issue or if your product owner is unavailable to answer a functional question.

Gurus are also responsible for the code base of the applications under their responsibility. Hence, when you are done with a task, the guru responsible for the app on which you worked on will review your PR.

Test your code

We have an automatic testing bot called Runbot. Any branch or PR in odoo or odoo-dev will be automatically tested and built on it. All you have to do is commit, push and wait for the verdict.

For more information on how to test Odoo modules, you can take a look at the testing documentation.

Never say "My code is ready" if it is not "green" on Runbot. (or the "runbot police officer" (MOC) will handcuff you !)

Build color	Meaning
white	pending — Will be tested in a few minutes, waiting for an available core.
blue	testing — Running all modules' tests. Be patient, it can take between one and two hours.
green	success — All tests have passed. The branch is ready to be merged.
yellow	warnings — Your code triggered some warnings.
red	errors — Your code caused some errors.
grey	killed — The build has been killed either manually or by pushing a new commit.

(Remember: if you break the master, you bring breakfast the next day. Period.)

6. Tips and Tricks

You don't have to go through all of this right now but it would be good if you read each tip at least once in the upcoming weeks. Some of them are more important than others but it's very likely that you'll need each of them sometime soon.

Develop in Odoo

Command line developer features

Read the documentation about command line developer features to learn more about tools that will allow you to spare quite some time when developing Odoo modules.

Intercept mails locally

To avoid spamming your own email address with test emails, you can use MailHog. MailHog is an email testing tool for developers that runs a local webmail client and intercepts mails locally.

Download and install the latest release from MailHog's GitHub.
Run chmod +x MailHog_linux_amd64 on it.
Execute it with ./MailHog_linux_amd64.
When running Odoo, use the following parameters: --smtp=localhost --smtp-port=1025.
In your browser, visit http://127.0.0.1:8025/.

Avoid rewriting everything from scratch

If you need to interface with common Odoo features such as the chatter, you can rely on mixins. They are Odoo models exposing useful methods through inheritance.

To learn and play with mixins, visit this repository. This module for a plant nursery is training material developed for the OXP 2018. You don't need to code it on your side. But you can check the presentations in the /static/pdf directory and play with the module to discover some magic features in Odoo.

Don't joke with security

Every day we hear about data leaks and attacks in the newspapers. We expect you to be aware and careful about how to avoid security breaches in your future developments.

You already defined new models in your training. Did you check the access rights and define record rules on it ? Are you sure your module is not an open door to SQL injections ? Did you use getattr or t-raw in your code?

This section aims to avoid seeing this kind of thing after merging:

No or wrong access rules on models.
Introduction of public methods that should actually be private.
Wrong manipulation of access tokens.
No or wrong ir.rules (restriction rules) on models.
Introduction of SQL injections.
etc.

Please check this presentation from Oliver Dony (odo) about common mistakes that you should absolutely avoid in your future developments.

In your future developments, please always use this security checklist to double check your development and avoid further embarrassing issues.

Safely overwrite remote branches

To avoid overwriting a remote branch if new commits were added to it, use git push --force-with-lease instead of git push --force. It is mostly unnecessary but will have your back if it happens that someone pushed some commits on your branch, which may happen during code review, for instance.

Understanding the release cycle

By default, all new features are developed for the next SaaS release and merged into the branch master. For instance, if the last (not necessarily released) version is SaaS 13.1, then the branch master represents the upcoming SaaS 13.2 release.

After about 2 months of committing in master, the freeze manager (MOC) freezes master as the new version by branching it. All pending work that has not yet been merged thus missed its target version. In post-freeze, it is no longer possible to make model changes as the migration team is busy writing the migration scripts. In practice, some late tasks are given the right to ignore this rule. If the new SaaS is the last before OXP (usually SaaS X.5), it later gets renamed in "Release X+1".

When migration scripts are ready for a new version, it is deployed on https://next.odoo.com for it to undergo exploration tests. After a time, it is deployed in production (odoo.com).

After about one month of internal use on odoo.com, a SaaS is considered stable enough to be officially released. Major versions (e.g. 13.0) do not follow this cycle and are systematically released during the OXP.

Master the Runbot

Match your branches between `odoo/odoo` and `odoo/enterprise`

If your current work is exclusively based on odoo/odoo, it's pretty straight forward since you will only have one branch for Community.

If your current work impacts both odoo/odoo and odoo/enterprise, set the exact same name for your two branches so that the Runbot knows that your Enterprise modules should be built on your Community branch.

If your current work is exclusively based on odoo/enterprise, make sure to make the name of your branch start with <version>- where version is the odoo/odoo branch that the build should target.

Identify non-deterministic errors

It may happen that your build's tests finish with warnings (yellow) or errors (red) that are not your doing. If, when reading the code and the build logs, you cannot establish a link between your changes and the error, you're most likely facing non-deterministic errors. These are randomly failing tests that were merged in a previous commit but failed in your build. Check the (non-exhaustive) pad of false positives to see if it has already been reported.

Since the MergeBot only accepts to merge PRs whose build is green (all tests passing), you will need to rebuild the branch manually (login with your Odoo account and hit Rebuild (ask your guru for the rights if you don't have them)) or push on top of it.

Intercept mails on the runbot

Just like in Intercept mails locally, the runbot uses MailHog to intercept mails. You can consult them at the runbot's address on port 1080.

Work with Odoo

Submit a bug report

If you find a bug in Odoo with traceback, make sure that you can reproduce it on the runbot (try different builds) and investigate to find out in which version it appeared. Then log in with your Odoo account on https://www.odoo.com/help and fill out the form with as follows:

Edition & Hosting: "Odoo Online"
Database URL: "openerp.odoo.com"
Ticket type: "A bug with a traceback"
Reproducible on Runbot: checked

Detailed description: Follow the example template below

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

Impacted versions:

- 13.0
- 13.1

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.00

Expected behavior:

- Total price of 20.00 (2 * 10.00 = 20.00)

This will create a task in the project Help and directly escalate it to the "Bug Fixes" stage. Give enough details to allow to reproduce the issue and mention the versions that are impacted.

If you find a bug without traceback, follow the same steps but change the ticket type to "A bug or a wrong behavior but no traceback" and uncheck "Reproducible on Runbot". This will still create the ticket but let the functional support team assess it and forward it to the right team.

Don't screw up your account with a trial db

If, for some reason, you need to create a trial database, make sure you're not logged in to your Odoo account. Otherwise, your form submission will update your Odoo account, name included.

7. You're done !

Congratulations if you read this whole document and good work !

Welcome to Odoo!