Odoo Help

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.

on 9/15/15, 12:21 AM

To crazy my ideas?

Axel Mendoza
on 9/20/15, 4:30 PM
Yenthe Van Ginneken
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.

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.

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.

Yenthe Van Ginneken
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)

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 community is for professionals and enthusiasts of our products and services. Read Guidelines

Question tools

2 follower(s)


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