Odoo Help


[ Suggestions required ] Instance wise Addons path + Database wise Addons path are feasible in Odoo ?

Emipro Technologies Pvt. Ltd.
on 9/14/15, 8:11 AM 2,010 views

Hello All,

I am just seeking other Odoo expert's suggestions on whether following case may be possible/feasible or not in Odoo V8.  

We all very well know that, through Odoo conf file we can set Addons path. But sometimes, we don't want to show some modules in some specific databases. For example, in order to make invisible that module, if we delete module from module list, then also someone can easily make them available them via "Update Module List" menu. And sometimes, when we host Odoo for multiple customers in one server, then we don't want to show modules of customers to each other's.

Possible Way 1 :

So what I was thinking, that if somewhere in configuration parameter ( Settings >> Technical >> Parameters >> System Parameters menu), we can set addons path. Then at the time of database initialize from login screen, those specific modules also should be initialize.

So Odoo basic module's path will be taken from standard config file and customer specific modules will be taken from each database's configuration parameter. For example 3 paths specified in conf file and 1 path specified at configuration parameter under particular database then when you select the database at login time, from 4 paths, (3 from config, 1 for particular database) modules will be initialized.

Let me write some other alternative ways in case if above idea will not work. Other possible ways can be as follows,

Note : Generally end customers doesn't like to do any settings from py files so following ways would not be more suitable for end users. They like the policy "As more as from front end & as less as from back end". 

Possible Way 2 :

We can add one more attribute in "__openerp__.py" file like

in_databases : ['test1','test2']
So while doing "update module list" we will skip this module's visibility if current database is not in list of that parameter. Off course, in this custom module, there must be "auto_install" set to "True", otherwise someone can uninstall this module and our extended "update module list" method will not worked. ;) ;) ;)

Possible Way 3 :

We can add one more parameter in conf file which shall be kind of a dict ( "{}" ) in conf file.

addons_db_path = {'test1' : '/opt/odoo/test1_addons', 'test2' : '/opt/odoo/test2_addons'} 
so along with addons_path this new attribute will specify addons path for specific databse when some one click on "update module list"

Benefits of this kind of feature would be,

  • Database wise specific modules.

  • One database's specific modules will not be visible to any other database.

  • You can keep the same name but different features inside the modules.

  • You can easily manage different customer's modules into one single instance of Odoo.

  • Client specific modules will be total secured.

I am very keen and hopeful to get opinions of Odoo experts from this forum.

Axel Mendoza
On 9/14/15, 12:10 PM

Hi @Empiro, this is very interesting topic, +1 for your question, I'd like to give you some ideas that I've managed since v7. 

In several terms it's not feasible right now to have a single Odoo instance for sharing modules to multiple database and it's due to your question topic, every database doesn't have/manage their own modules like in differents locations, meaning that you cannot have for the single instance database 1 using module A from /opt/odoo/repos/dev/A and database 2 using the same module A from /opt/odoo/repos/master/A since it will forget about one of those since the addons_path need to be composed of those two paths. Also like in your case databases 1 & 2 will have the modules specific of one visible to the other. And a module update could break one of the database without you know affecting the clients and normal use

Since Odoo need the modules loaded to do several computations and caches, the startup engine configure the threads/workers/process to use the modules loaded from the config addons_path. 

In my opinion the addons_path config need to be a triple like (worker, database, addons_path), something like if one worker get spawn it need to be database specific and needs to load the addons_path module code for that database, then you need to manage workers like a pool and also have a way to correctly use an specific addons_path code for assume requests to that database.

What I'm talking about is to have a worker/process/thread memory for addons_path isolation. In this case the database will have their own modules since the workers that managed it will be contains the specific addons_path and using Update module list will cause no harm. Using this approach the workers will be memory variables since they don't need to load all the modules for all the databases universe, they just need to load the specific database configuration. I think that a worker master for every database need to exist in order to spawn/destroy child workers for every database just with a fork but without been a fork of the main Odoo process, just using interprocess comunication with Odoo master process

- Odoo master process
    - Worker master for database 1
        - Worker child process for database 1
        - Worker child process for database 1
        - Worker child process for database 1
    - Worker master for database 2 
        - Worker child process for database 2
        - Worker child process for database 2
        - Worker child process for database 2

Because features like this are None, we are using the approach of create one instance of Odoo per database(normally a customer or using the same instance for others tests database of the development/production main one) but without having a big instance of modules for database 1 and 2. Using Nginx for dispatch to the needed instance. That way the database instance will manage only the modules of their specific addons cloned and managed specifically for the instance using fabric in combination with an Odoo UI deploy module tool

Thanks @Axel, I will read and back to you with my thoughts. But +1 for your wonderful effort and time.

Emipro Technologies Pvt. Ltd.
on 9/15/15, 12:21 AM

To crazy my ideas?

Axel Mendoza
on 9/20/15, 4:30 PM
On 9/14/15, 8:38 AM

Hi Emipro,

I was wondering why you would want to make these things so complex. Imagine building your in_databases like this:

in_databases : ['test1','test2']

Imagine that you have 20 customers on your server. This would mean that you would have to modify this code every time in your module. That sounds like a pain and sooner or later you will make errors in this. If I understand you correctly you basically don't want to show custom modules to all your customers/users. Wouldn't it be an option to create a new option in your __openerp__.py like this:

admin_only_module: 'True'

If the option is true the module will be visible in all databases but only for the superadmin user (id 1).
If the option is set to 'False' it will be visible to any database and any user.

Wouldn't this solve your problems?

Update: Now that you've added an extra response on my answer and your extra samples I would honestly say that your option two sounds the best. This sounds like a more flexible way then option 1. I would personally use option #2 if it was up to me.


@yenthe this "admin_only_module" would not be good option, because of when you give demo database to your client obviously they will/should/must able to login via admin and they can easily view all the modules of other clients. I have write two alternative ways when the explanation of my main paragraph is not feasible. So by database wise addons path is not good way ? Please think on this. However we should also design system in so simple way that end customer, who don't know __openerp__.py file can easily configure their addons path. "More from frontend and less from backend". Appreciating your prompt response and that will lead to +1 upvote from me.

Emipro Technologies Pvt. Ltd.
on 9/14/15, 8:56 AM

@Yenthe By the way, there is very rare cases in which anyone needs to manage 20+ clients from single instance of Odoo.

Emipro Technologies Pvt. Ltd.
on 9/14/15, 9:02 AM

@Emipro why would you give the admin account to any user at any time? You can create a new user with, I assume, all the rights and accesses that you'd ever need. Our customers never get access to the main admin account for a specific Odoo. Judging by your answers I would honestly say to go with option #2. Thats a pretty clean solution.

on 9/14/15, 9:10 AM

@Yenthe its quite normal, we manage separate database for each customers then they might need admin account. In normal case or specially to our clients we are giving total database access to our clients. They can do anything inside their account. One of the simple example I would like to give you is suppose you host your database at Odoo itself. Now you won't need admin access to manage your database separately ???????????? Now in case if Odoo don't want to show Xyz customer's module to you then what is the available option ? That's what I am trying to figure out. ( This is just example, please don't say that Odoo don't allow to host any other community modules :D)

Emipro Technologies Pvt. Ltd.
on 9/14/15, 9:27 AM

In this case I go with option 1 or an external cache like Redis

Axel Mendoza
on 9/14/15, 12:55 PM
Solanki Shamji
On 9/18/15, 5:42 AM


My suggestion is that

If you provide SAAS to the customer than dont give access of setting menu or module installation.

Give separate user for separate client and manage using access right.



About This Community

This platform is for beginners and experts willing to share their Odoo knowledge. It's not a forum to discuss ideas, but a knowledge base of questions and their answers.


Odoo Training Center

Access to our E-learning platform and experience all Odoo Apps through learning videos, exercises and Quizz.

Test it now

Question tools

2 follower(s)


Asked: 9/14/15, 8:11 AM
Seen: 2010 times
Last updated: 11/21/15, 6:11 AM