Passa al contenuto
È necessario essere registrati per interagire con la community.
Tutti gli articoli Persone Badge
Etichette (Mostra tutto)
odoo accounting v14 pos v15
Sul forum
La domanda è stata contrassegnata
customizationbest-practiceDevelopment
3 Risposte
18922 Visualizzazioni
Avatar
Sveng

Am new-ish to Odoo with limited Odoo development experience. Currently on Odoo.sh EE.

One of the great things about Odoo is the ability to customize almost anything. The downside of this is that most things need to be done in code.

Usually there are a multitude of changes/customizations (minor ones but many) that are made e.g. remove fieldA from form x in app/module1, add fieldB to form y in app/module2, create a custom module 3 for new functionality not present, change the domain for a particular search etc.

As listed above these changes are made in a number of different modules.

Would it be wrong to create a single 'customization' module and include all changes in this one module (am assuming this should be possible) instead of creating a different module e.g sales_custom, purchase_custom contacts_custom etc. and place the changes relevant to each module in their own package.

What is the best practice in this regard? Which is the most practical/manageable based on your experiences to manage customizations?

Having all changes in one module would in my mind reduce complexity and make it easier when it comes to upgrades etc.

This would not apply to customizations that are standalone complete new functional modules which I would make self contained modules. 

Avatar
Abbandona
Avatar
Ray Carnes (ray)
Risposta migliore

I disagree.  

If you moved to a new home, wouldn't you want all kitchen related things kept together, rather than a giant container with the oven next to your bed which is next to your bike which is next to your shoes?  You would keep related things together otherwise you would have to search through the entire container to find something to wear to your new job (which you start before you finish unpacking).

If something isn't working, you (or most likely, someone else) will have to search through the entire module to find out what is wrong, you won't be able to uninstall each module until you find the one that introduced the problem.

Also, you likely won't be delivering ALL your features to your Customer at the same time. 

  • You build 5 things
  • They sign off on the 4 that are ready
  • They can't use ANYTHING until EVERYTHING is finished.

It can quickly become too unwieldy to manage as you scale with more developers and more features.

If you want additional fields on the crm.team model that are related to the CRM App, create a new module called "crm_enhance".

If you want additional fields on the crm.team model that are related to the SALES App, create a new module called "sale_enhance".

If you want additional fields on the crm.team model that are related to BOTH, create a new module called "sale_crm_enhance".

If you want additional fields on the crm.team model that relate just to the TEAM ITSELF, create a new module called "sales_team_enhance".

This is what we do. It is how we have scaled development amongst multiple teams working on multiple features, including when it comes time to upgrade (which we do now with automated scripts for each module).

The SCAFFOLD command creates a module stub for you, and if you modify what is created to suit what you need, you can reuse it as a template each time you need a new module.

Avatar
Abbandona
Avatar
Sveng
Autore Risposta migliore

Thanks guys for the perspective. I tend to agree with Ray on this from a devops perspective.

@Ray, I would be interested to hear more regarding your scripting, is this for a managed build / test / deploy process or full continuous integration?

For a single customer/installation (internally / self-managed) in a simple low volume change environment the single module method is probably ok. This is what I found at a customer in this specific instance and hence my question.

As I explore Odoo I am finding configuration & change management one of the most challenging and least developed/documented areas.

Avatar
Abbandona
Avatar
Baiju KS
Risposta migliore

Hi Sven,

Making modules for each bit of customization sound very tedious, the only advantage here is you can simply uninstall a module if you want to remove that feature quickly. If everything is in one module, for this you have to edit the module and upgrade the module. Even with this, it doesn't make much sense to make different modules for small changes, because in long run for a project it will create trouble for adding dependency and locating past done changes.

So if the customization is not a standard reusable functionality, it's useful to have it in one module. If it's for the same project it will eliminate many issues in the long run.

Hope this helps.

Avatar
Abbandona
Post correlati Risposte Visualizzazioni Attività
Preload a new repair order
Development
Avatar
0
nov 24
10
module Extention/ Customization
customization
Avatar
Avatar
Avatar
Avatar
Avatar
5
ago 24
4067
[meta] Why do some questions get answers and others do not? Risolto
best-practice
Avatar
4
mag 25
19403
Creating demo data for our modules
development xml customization demo_data best-practice
Avatar
Avatar
Avatar
2
ago 23
5504
How to custom our Odoo LMS page?
customization
Avatar
0
gen 22
3185