Odoo homepage screen

Installing Odoo frontend and backend on different servers

In this tutorial I will teach you how to separate your Odoo frontend and backend. I will install the Odoo codebase/frontend on one server and the backend (your PostgreSQL server and database) on another server. You will learn how to configure both Odoo and PostgreSQL to achieve this.

1. Introduction

In order to achieve and demonstrate this setup to you I will be working with two virtual machines.
I will refer to the Odoo codebase/frontend server as the ‘frontend server’. The PostgreSQL server and database will be named ‘backend server’ throughout this tutorial.
My frontend server has the IP and my backend server has the IP
Tip: Make sure that both your servers have a fixed IP, otherwise your setup will break due to IP changes!

2. Configuring the backend server

Let us start with the configuration of the backend server. This server will contain the PostgreSQL server and the database(s).

2.1 Installing postgreSQL

Open up a terminal on your backend server and install PostgreSQL if you haven’t yet:

2.2 Creating the PostgreSQL user

Now create a new PostgreSQL user. Make sure that the PostgreSQL username matches with the username of the user running Odoo on your frontend server. In my example I will create a new PostgreSQL user with the name “odoo11”:

After you execute this command the system will ask you for a password for this user. Fill in a password and confirm this password again.
Tip: Don’t forget to remember this password, you’ll need it later on.

2.3 Configuring pg_hba.conf

After installing the PostgreSQL server and creating the user we now need to configure the remote connections. As our backend server will be used for the database connections our frontend server needs to be able to access it. Open up your frontend server and get the IP of the server. In my example my frontend server has the IP Now open up your pg_hba.conf file on your backend server:

Scroll in this file and search for the following line of code:

Add a new line after the existing one which contains your frontend server its IP address. As you don’t want to use the exact IP address you should use the /24 subdomain. In my example this results to instead of Your configuration file should now look like this:

Finally, save your file and close it. Your PostgreSQL now knows that you want to allow connections from the backend server (IP

2.4 Configuring postgresql.conf

Your PostgreSQL still needs to know the listen address of your frontend server too though. To achieve this we have to edit the postgresql.conf file:

Find the ‘listen_addresses’ line, which looks like this by default:

Now add in the IP of your frontend Odoo server (in my example

Tip: Don’t forget to remove the # in this line because otherwise this line will be skipped!
Save this file and close it.
You’ve now applied all the changes that you need to do on the backend server. Next reload the PostgreSQL service in order to apply all the changes:

3. Configuring the frontend server

Your backend server is done now. Switch to the frontend server and open up your Odoo configuration file.
Tip: If you haven’t installed an Odoo yet you can follow my tutorial here
Typically your Odoo configuration file is under /etc/ and is named your-odoo.conf:

Add or change the following parameters in the configuration file:

Finally, restart your Odoo service to reload your Odoo configuration:

When you now browse to your Odoo instance (on your frontend server) you’ll see that your new Odoo is ready to use.
Odoo homepage screen
That is all! You’ve now setup your own Odoo instance where the frontend and backend are split between two servers.

4. Tips

While this is everything that you need in order to split up the backend and frontend of Odoo there are still some things to consider.
Because of security reasons you’ll most likely want to encrypt all the data and place everything on SSL. This also includes the calls from the frontend server to the backend server.
After you’ve created a new database you should check if the database is in fact created on the backend server instead of on the frontend server. You can do this executing the following commands (one by one) on your backend server:

After running these commands you can see an overview of your databases and to what user the database belongs. In my example you can see a new database named ‘ABC’ which is owned by my Odoo/PostgreSQL user ‘odoo11’:
Database overview result backend

5. Conclusion

Setting up an Odoo instance where the frontend and the backend are split is actually quite easy. Due to the built-in parameters from Odoo it is very easy to configure the frontend side. When you split the frontend and backend up and apply extra security – such as HTTPS connections and VLAN’s – you’ll have a safer and more controlable Odoo instance.
If you’d like to learn more about the deployment of servers and the default Odoo parameters you can have a look at the official documentation.

Has this tutorial helped you, do you have any feedback or questions? Post away!
Tutorial sponsored by Oocademy


Creating security groups in Odoo

Hi guys,

In this tutorial I will teach you how to create security groups, how to add specific users to these groups and how to show/hide menu’s depending on in which group the user is in. An example of the result after this tutorial:
Example settings under user

1. Creating a model

The first thing to do is to create a model. If you already have an existing model you can skip this chapter and continue with part 2.
Still reading? Alright, let us create a new model. In this tutorial I will create a new model named ‘demo.access.rights’, with just one simple field. Create a new Python file under the ‘models’ directory and create a new model with a field:

2. Creating the security groups

Alright, now that we have a model, the next thing to do is to create the security groups with the specific rights that you would like to give to this group.
First of all open up the ir.model.access.csv file (under security/) and look at the top of the file:
Security CSV file
When you look at this file you’ll see that there are a few columns. Let me explain them a bit into detail:

  • Id: An unique identifier for the record (they should always be unique!)
  • Name: This is the description that is shown in the front-end and is the name for the security group.
  • model_id:id: The name of the model where you want to create a security rule for. Replace the ‘.’ by an ‘_’. If you have a model named ‘this.model’ it should become ‘this_model’ and it should always be prefixed with model_. So this would become ‘model_this_model’ in my example.
  • group_id:id: An unique name of the group.
  • perm_read: If this is set to 1 it means that all users that are in this group have read acces on this model. If it is set to 0 it means that the users don’t have read rights.
  • perm_write: If this is set to 1 it means that all users that are in this group have write acces on this model. If it is set to 0 it means that the users don’t have write rights.
  • perm_create: If this is set to 1 it means that all users that are in this group have create acces on this model. If it is set to 0 it means that the users don’t have create rights.
  • perm_unlink: If this is set to 1 it means that all users that are in this group have delete acces on this model. If it is set to 0 it means that the users don’t have delete rights.

Let us start writing security groups. In my example I will create two groups: one with full rights for reading, writing, creating and deleting (admin behaviour) and one group that can only read records. Let me show you the result and I will then explain it further!

Look at those two rules for a minute and try to figure out what they do.
I’ve created two lines, which means two groups, that are both for the model ‘demo.access.rights’, where the first group has all rights on the model and the second group can only read data (look at the 1,1,1,1 and the 1,0,0,0).
Do you notice something else? There is a group_id in the field named ‘user_access_rights_demo.group_manager’ on the first line and ‘user_access_rights_demo.group_user’ on the second line. What do these two mean? Well, the first part (‘user_access_rights_demo’) is the name of the module where you are creating groups for. The second part, ‘group_manager’ will link to an XML record in which we specify the rest of the details. Add those lines to your CSV file, save it and then close it.

3. Creating the groups and selection in XML

Now that you’ve written the groups in the CSV we have the rules but in the CSV file they link to ‘group_manager’ and ‘group_user’, which we still haven’t made anywhere. So let us make them!
Create a new XML file under the ‘security’ folder so that we can write the XML side. In my example I’ve named the file ‘user_groups.xml’ as you can see here:
XML security file
We now need three things:

  • A group named ‘group_user’
  • A group named ‘group_manager’
  • A record that will link these both groups in a dropdown, in order to show it in the user his form.

Let’s start by writing a record that will show our both groups in a dropdown:

This will create an option in the user his form that has the label ‘Demo module access’ and a description ‘User access level for this module’. The sequence can be used to specify where it should come in the view. When you’re done with this part it will show this selection:
Example security settings

One down, two to go. We now need to create two group records (‘group_user’ and ‘group_manager’) so that the CSV can find and use these groups. The code should look like this:

Let me explain the code a bit more. The ‘name’ field will be the text that is shown to the user in the front-end.
By setting the ‘users’ field (which links to another group user) you can say that by default users that belong to the other group should be added to this specific group. For example: with users set to ‘base.user_root’ I will by default enable this value for the user. By setting the field ‘implied_ids’ on the ‘group_manager’ I’m saying that if the user has the manager rights that he should also have rights as a user (ref(‘user_access_rights_demo.group_user’) does this).

That is all! You’ve just created your own security groups and made them available on the user his form so that you can configure this for every user on his own.

4. Applying groups to views

After you’ve created your own groups and rules you’ve got a broad set of options to configure Odoo depending on the user his rights.
Let me give you an example with two menuitems that are available for one of two groups. If you do not need to know this you can skip to the conclusion (part 5), otherwise read on!
Alright, I will create two menuitems, one of them will be available to the user group and both menu’s will be available to the manager group. How would this look in XML? Like this:

This will create a new top menu named ‘Access rights demo’, with a menu named ‘Rights demo’, with two menuitems named ‘User records’ and ‘Admin records’, which looks like this:
Example menuitems
By simply adding the ‘groups=’ tag on the menuitems I can specify which group can access which menuitem! It is as simple as that. When I would now create a new user with the ‘User’ rights he would only see the menuitem for the user and not the admin menu:
User menuitem

5. Conclusion

The security groups and security rules are not very hard to set-up but allow you a very broad range of configuration. You can specify what a user can see just by in which groups or security rules the user is in. This allows you to show or hide menuitems, fields and options with very little effort. The possibilities are endless!

Do you want to try the demo code and see the source code of this tutorial? You can view it on my Github account.
Has this tutorial helped you, do you have any feedback or questions? Post away!
Tutorial sponsored by Oocademy