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

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

Hello,

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.

Thanks.

Shamji