Skip to Content
Musisz się zarejestrować, aby móc wchodzić w interakcje z tą społecznością.
Wszystkie posty Osoby Odznaki
Tagi (Zobacz wszystko)
odoo accounting v14 pos v15
O tym forum
To pytanie dostało ostrzeżenie
customizationbest-practiceDevelopment
3 Odpowiedzi
19022 Widoki
Awatar
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. 

Awatar
Odrzuć
Awatar
Ray Carnes (ray)
Najlepsza odpowiedź

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.

Awatar
Odrzuć
Awatar
Sveng
Autor Najlepsza odpowiedź

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.

Awatar
Odrzuć
Awatar
Baiju KS
Najlepsza odpowiedź

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.

Awatar
Odrzuć
Powiązane posty Odpowiedzi Widoki Czynność
Preload a new repair order
Development
Awatar
0
lis 24
10
module Extention/ Customization
customization
Awatar
Awatar
Awatar
Awatar
Awatar
5
sie 24
4099
[meta] Why do some questions get answers and others do not? Rozwiązane
best-practice
Awatar
4
maj 25
19463
Creating demo data for our modules
development xml customization demo_data best-practice
Awatar
Awatar
Awatar
2
sie 23
5539
How to custom our Odoo LMS page?
customization
Awatar
0
sty 22
3200