Diskusi: Strategi Mengurangi Ketergantungan File Modul Custom di Odoo
Diposting pada 27 Jun 2026, 09:23
Halo teman-teman praktisi Odoo di sini,
Saya Gunawan dari Jakarta, kebetulan di kantor kami pakai Odoo ERP dan saat ini sedang fokus untuk merapikan beberapa modul custom yang sudah jalan. Nah, belakangan ini saya perhatikan, kalau kita bikin customisasi di Odoo, kadang rasanya file-file pendukungnya (mulai dari Python, XML, sampai aset JS/CSS) jadi cukup banyak dan tersebar, terutama kalau ada banyak fitur kecil yang saling terkait. Ini kadang bikin sedikit kewalahan pas mau update, maintenance, atau bahkan deploy ke staging/production environment.
Saya penasaran nih, ada nggak ya best practice atau tips dari teman-teman di sini, bagaimana caranya kita bisa "depends less" atau mengurangi jumlah file yang harus di-maintain untuk sebuah fitur atau modul custom di Odoo? Misalnya, apakah ada strategi untuk bundling aset JS/CSS agar tidak terlalu banyak file terpisah? Atau mungkin ada cara efektif untuk merampingkan struktur folder dan file Python agar lebih kohesif tanpa kehilangan modularitasnya?
Tujuan utamanya sih biar code base kita lebih bersih, lebih mudah di-manage, dan performanya juga bisa lebih optimal. Mungkin ada yang punya pengalaman atau sudah menerapkan pendekatan tertentu yang bisa di-share?
Terima kasih banyak sebelumnya atas pencerahannya! Salam Odoo!
Balasan (1)
Halo Mas Gunawan dari Jakarta! Salam Odoo juga dari komunitas.
Wah, ini pertanyaan yang relevan banget dan sering jadi "PR" kita sebagai praktisi Odoo, terutama di proyek-proyek yang sudah berjalan lama atau melibatkan banyak kustomisasi. Memang betul, Mas, kalau tidak diatur dengan baik, file-file custom di Odoo bisa jadi lumayan 'berantakan' dan bikin pusing pas mau maintenance atau upgrade. Saya sangat paham dengan keresahan Mas Gunawan ini.
Mungkin saya bisa coba share beberapa pendekatan atau best practice yang bisa Mas Gunawan pertimbangkan untuk mengurangi ketergantungan file modul custom di Odoo agar lebih ramping dan mudah di-manage.
### 1. Strategi Bundling Aset JS/CSS
Untuk aset JavaScript dan CSS, Odoo punya mekanisme assets bundling yang cukup powerful, Mas. Daripada membuat banyak file XML untuk setiap file JS/CSS kecil, Mas bisa mencoba strategi ini:
Gunakan satu file XML untuk mendefinisikan aset modul Anda: Buat satu file XML (misalnya `views/assets.xml`) di modul custom Anda. Di dalam file ini, definisikan satu atau dua bundle aset utama (misalnya `web.assets_backend` atau `web.assets_frontend`) menggunakan tag `` dengan atribut `inherit_id`.
Sertakan semua file JS/CSS terkait dalam satu bundle: Di dalam template `assets` tersebut, Mas bisa menyertakan semua file JS/CSS yang dibutuhkan oleh modul Anda. Odoo akan otomatis melakukan bundling dan minifikasi file-file ini saat di-deploy ke mode produksi, yang tentunya akan membantu performa.
Contoh:
```xml
```
Dengan begini, Mas Gunawan hanya perlu maintain satu file XML aset untuk semua JS/CSS di modul tersebut.
Manfaatkan ES Modules (Odoo 13+): Untuk JavaScript, mulai Odoo 13 ke atas, Mas bisa memanfaatkan fitur ES Modules. Ini memungkinkan Mas untuk mengimpor modul JS lain di dalam file JS utama Anda, mengurangi kebutuhan untuk mencantumkan setiap file JS secara terpisah di XML dan membuat kode lebih modular di sisi JavaScript-nya sendiri.
### 2. Merampingkan Struktur Folder dan File Python
Untuk bagian Python dan XML (khususnya untuk definisi view, security, dan data lainnya), ini kuncinya ada di pengelompokan logis, Mas.
Python (models, wizards, controllers, dll.):
Grupkan berdasarkan entitas atau fitur utama: Jika Mas punya beberapa model yang sangat terkait erat (misalnya `sale.order` dan `sale.order.line` custom fields/methods), pertimbangkan untuk menempatkannya dalam satu file Python (misalnya `models/sale_management.py`).
Hindari fragmentasi berlebihan: Terlalu banyak file Python kecil (satu file untuk satu fungsi atau satu metode) justru bisa bikin ribet. Tetap jaga modularitas, tapi tidak terlalu mikro.
Gunakan sub-direktori secara bijak: Untuk modul yang sangat kompleks, Mas bisa menggunakan sub-direktori seperti `models/`, `wizards/`, `controllers/`, `reports/`. Namun, pastikan isinya memang cukup banyak sehingga layak dipisah. Kalau hanya ada satu file wizard, cukup letakkan di `models/` atau di root folder modul jika `__init__.py` di sana mengimpornya.
Contoh struktur yang bagus:
```
your_module/
├── __init__.py
├── models/
│ ├── __init__.py
│ ├── sale_extensions.py # Model related to sale
│ ├── inventory_utils.py # Model related to inventory
│ └── common_wizards.py # All common wizards
├── views/
│ ├── sale_views.xml
│ ├── inventory_views.xml
│ └── assets.xml # For JS/CSS bundling
├── security/
│ └── ir.model.access.csv
└── __manifest__.py
```
XML (views, data, security):
Grupkan berdasarkan entitas atau jenis data: Mirip dengan Python, gabungkan definisi view untuk satu model (atau grup model yang terkait) ke dalam satu file XML. Misalnya, semua kustomisasi view untuk `product.template` bisa ada di `views/product_views.xml`.
Pisahkan security dan data: File `security/ir.model.access.csv` harus tetap terpisah. Untuk data lain (misalnya data demo, data konfigurasi awal), Mas bisa menempatkannya di `data/your_module_data.xml`.
Jangan buat file XML hanya untuk satu `ir.ui.view`: Jika Mas hanya menambahkan satu field atau mengubah satu atribut di sebuah view, Mas tidak perlu membuat file XML baru. Mas bisa menggabungkannya ke dalam file XML view yang sudah ada untuk model terkait.
### 3. Pemanfaatan Fitur Inheritance Odoo
Salah satu kekuatan utama Odoo adalah inheritance. Manfaatkan fitur ini sebaik mungkin, Mas:
Inheritance di Python: Gunakan `_inherit` untuk memodifikasi model yang sudah ada. Ini jauh lebih baik daripada membuat model baru dari awal untuk fitur yang hanya memodifikasi perilaku model standar.
Inheritance di XML: Gunakan `inherit_id` dan `xpath` untuk memodifikasi view yang sudah ada. Ini akan membuat kustomisasi Mas 'menempel' pada view original Odoo, sehingga lebih mudah di-manage dan cenderung lebih stabil saat upgrade minor (walaupun upgrade mayor tetap butuh perhatian).
Dengan menggunakan inheritance, Mas mengurangi kebutuhan untuk membuat file-file baru yang "terpisah" dari struktur Odoo standar.
### 4. Evaluasi Kebutuhan Sebelum Kustomisasi
Sebelum mulai ngoding, ada baiknya dievaluasi dulu, Mas:
Apakah fitur yang ingin dibuat mutlak membutuhkan kustomisasi kode?
Apakah bisa diselesaikan dengan konfigurasi Odoo standar (misalnya lewat Studio, menambahkan field lewat UI, atau mengaktifkan fitur tertentu)?
Apakah ada modul komunitas (OCA) yang sudah menyediakan fitur serupa dan bisa diadopsi?
Terkadang, sedikit konfigurasi bisa menggantikan beberapa file custom yang mungkin jadi beban di kemudian hari.
Dengan menerapkan pendekatan-pendekatan di atas, Mas Gunawan akan melihat codebase modul custom jadi jauh lebih bersih, lebih terstruktur, dan tentu saja lebih mudah untuk di-manage dan di-deploy. Ini juga akan sangat membantu tim Mas Gunawan saat melakukan maintenance atau debugging.
Semangat merapikan Odoo-nya, Mas Gunawan! Kalau ada pertanyaan lebih lanjut, jangan sungkan ya.
Wah, ini pertanyaan yang relevan banget dan sering jadi "PR" kita sebagai praktisi Odoo, terutama di proyek-proyek yang sudah berjalan lama atau melibatkan banyak kustomisasi. Memang betul, Mas, kalau tidak diatur dengan baik, file-file custom di Odoo bisa jadi lumayan 'berantakan' dan bikin pusing pas mau maintenance atau upgrade. Saya sangat paham dengan keresahan Mas Gunawan ini.
Mungkin saya bisa coba share beberapa pendekatan atau best practice yang bisa Mas Gunawan pertimbangkan untuk mengurangi ketergantungan file modul custom di Odoo agar lebih ramping dan mudah di-manage.
### 1. Strategi Bundling Aset JS/CSS
Untuk aset JavaScript dan CSS, Odoo punya mekanisme assets bundling yang cukup powerful, Mas. Daripada membuat banyak file XML untuk setiap file JS/CSS kecil, Mas bisa mencoba strategi ini:
Gunakan satu file XML untuk mendefinisikan aset modul Anda: Buat satu file XML (misalnya `views/assets.xml`) di modul custom Anda. Di dalam file ini, definisikan satu atau dua bundle aset utama (misalnya `web.assets_backend` atau `web.assets_frontend`) menggunakan tag `` dengan atribut `inherit_id`.
Sertakan semua file JS/CSS terkait dalam satu bundle: Di dalam template `assets` tersebut, Mas bisa menyertakan semua file JS/CSS yang dibutuhkan oleh modul Anda. Odoo akan otomatis melakukan bundling dan minifikasi file-file ini saat di-deploy ke mode produksi, yang tentunya akan membantu performa.
Contoh:
```xml
```
Dengan begini, Mas Gunawan hanya perlu maintain satu file XML aset untuk semua JS/CSS di modul tersebut.
Manfaatkan ES Modules (Odoo 13+): Untuk JavaScript, mulai Odoo 13 ke atas, Mas bisa memanfaatkan fitur ES Modules. Ini memungkinkan Mas untuk mengimpor modul JS lain di dalam file JS utama Anda, mengurangi kebutuhan untuk mencantumkan setiap file JS secara terpisah di XML dan membuat kode lebih modular di sisi JavaScript-nya sendiri.
### 2. Merampingkan Struktur Folder dan File Python
Untuk bagian Python dan XML (khususnya untuk definisi view, security, dan data lainnya), ini kuncinya ada di pengelompokan logis, Mas.
Python (models, wizards, controllers, dll.):
Grupkan berdasarkan entitas atau fitur utama: Jika Mas punya beberapa model yang sangat terkait erat (misalnya `sale.order` dan `sale.order.line` custom fields/methods), pertimbangkan untuk menempatkannya dalam satu file Python (misalnya `models/sale_management.py`).
Hindari fragmentasi berlebihan: Terlalu banyak file Python kecil (satu file untuk satu fungsi atau satu metode) justru bisa bikin ribet. Tetap jaga modularitas, tapi tidak terlalu mikro.
Gunakan sub-direktori secara bijak: Untuk modul yang sangat kompleks, Mas bisa menggunakan sub-direktori seperti `models/`, `wizards/`, `controllers/`, `reports/`. Namun, pastikan isinya memang cukup banyak sehingga layak dipisah. Kalau hanya ada satu file wizard, cukup letakkan di `models/` atau di root folder modul jika `__init__.py` di sana mengimpornya.
Contoh struktur yang bagus:
```
your_module/
├── __init__.py
├── models/
│ ├── __init__.py
│ ├── sale_extensions.py # Model related to sale
│ ├── inventory_utils.py # Model related to inventory
│ └── common_wizards.py # All common wizards
├── views/
│ ├── sale_views.xml
│ ├── inventory_views.xml
│ └── assets.xml # For JS/CSS bundling
├── security/
│ └── ir.model.access.csv
└── __manifest__.py
```
XML (views, data, security):
Grupkan berdasarkan entitas atau jenis data: Mirip dengan Python, gabungkan definisi view untuk satu model (atau grup model yang terkait) ke dalam satu file XML. Misalnya, semua kustomisasi view untuk `product.template` bisa ada di `views/product_views.xml`.
Pisahkan security dan data: File `security/ir.model.access.csv` harus tetap terpisah. Untuk data lain (misalnya data demo, data konfigurasi awal), Mas bisa menempatkannya di `data/your_module_data.xml`.
Jangan buat file XML hanya untuk satu `ir.ui.view`: Jika Mas hanya menambahkan satu field atau mengubah satu atribut di sebuah view, Mas tidak perlu membuat file XML baru. Mas bisa menggabungkannya ke dalam file XML view yang sudah ada untuk model terkait.
### 3. Pemanfaatan Fitur Inheritance Odoo
Salah satu kekuatan utama Odoo adalah inheritance. Manfaatkan fitur ini sebaik mungkin, Mas:
Inheritance di Python: Gunakan `_inherit` untuk memodifikasi model yang sudah ada. Ini jauh lebih baik daripada membuat model baru dari awal untuk fitur yang hanya memodifikasi perilaku model standar.
Inheritance di XML: Gunakan `inherit_id` dan `xpath` untuk memodifikasi view yang sudah ada. Ini akan membuat kustomisasi Mas 'menempel' pada view original Odoo, sehingga lebih mudah di-manage dan cenderung lebih stabil saat upgrade minor (walaupun upgrade mayor tetap butuh perhatian).
Dengan menggunakan inheritance, Mas mengurangi kebutuhan untuk membuat file-file baru yang "terpisah" dari struktur Odoo standar.
### 4. Evaluasi Kebutuhan Sebelum Kustomisasi
Sebelum mulai ngoding, ada baiknya dievaluasi dulu, Mas:
Apakah fitur yang ingin dibuat mutlak membutuhkan kustomisasi kode?
Apakah bisa diselesaikan dengan konfigurasi Odoo standar (misalnya lewat Studio, menambahkan field lewat UI, atau mengaktifkan fitur tertentu)?
Apakah ada modul komunitas (OCA) yang sudah menyediakan fitur serupa dan bisa diadopsi?
Terkadang, sedikit konfigurasi bisa menggantikan beberapa file custom yang mungkin jadi beban di kemudian hari.
Dengan menerapkan pendekatan-pendekatan di atas, Mas Gunawan akan melihat codebase modul custom jadi jauh lebih bersih, lebih terstruktur, dan tentu saja lebih mudah untuk di-manage dan di-deploy. Ini juga akan sangat membantu tim Mas Gunawan saat melakukan maintenance atau debugging.
Semangat merapikan Odoo-nya, Mas Gunawan! Kalau ada pertanyaan lebih lanjut, jangan sungkan ya.