Odoo Help

9 Answers

Axel Mendoza

--Axel Mendoza--
| 7 8 8
Camaguey, Cuba
--Axel Mendoza--

DevOps - Full stack - Software Architect - Developer - Technology Integrator

I could help you to develop anything and solve complex problems based on technologies, integrations and tricky stuffs mostly in Python with OpenERP/Odoo, Zato, Django and many others frameworks programming languages and technologies.

I offers consulting services to anyone with an unanswered questions or needs for customizations. Think about it, maybe it's better to have an expert to solve your issues and projects than having a full-time employee trying to understand what to do and how

Reach me at aekroft@gmail.com

Axel Mendoza
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

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

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

Axel Mendoza
9/20/15, 4:30 PM

To crazy my ideas?


Yenthe Van Ginneken

--Yenthe Van Ginneken--
| 8 8 10
--Yenthe Van Ginneken--

My Odoo blog: http://www.odoo.yenthevg.com/

My Twitter: https://twitter.com/Yenthe666

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


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

@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.
9/14/15, 9:02 AM

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

Yenthe Van Ginneken
9/14/15, 9:10 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.

Emipro Technologies Pvt. Ltd.
9/14/15, 9:27 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)

Axel Mendoza
9/14/15, 12:55 PM

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


Solanki Shamji

--Solanki Shamji--

| 5 2 7
Baroda, India
--Solanki Shamji--


Solanki Shamji
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.



Ask a Question
Keep Informed
2 follower(s)
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