Customizing Odoo — Module Structure and the Basics of Extension

Slides from the live webinar "Get to know Odoo customization" on 31 August 2023. These slides are in Japanese. Aimed at drawing software engineers toward Odoo, the deck takes two real business requirements and shows the standard-configuration answer next to the custom-code answer.

It goes all the way down into code and module structure.

What the deck covers

• What customizing Odoo means — configuration versus add-on development, and the Python, PostgreSQL, JavaScript, and QWeb stack behind it
• Why customization should be avoided where possible — it costs money, makes maintenance harder, and makes version upgrades painful
• Worked example 1 — showing the tax registration number on invoices for Japan's qualified invoice system. Document layout settings cover most of it; an add-on module handles the rest
• Worked example 2 — preventing deletion of accounting evidence attachments for Japan's electronic bookkeeping law, using attachment_delete_restrict to set which groups and users may delete per model
• Odoo's module structure — every feature is a module, stacked by dependency through base, web, mail, product, account, and sale. A custom module is technically the same kind of thing as a standard one
• What a module is made of — business objects, data files, web controllers, and static web assets
• Real code — __manifest__.py, a model definition, and the XML for inheriting a view
• Rules for writing modules — extend rather than override, go through the ORM, do not build what is not needed, split by business purpose, and do not breach licences
• Understanding open source — what OCA does, and how LGPLv3 differs from AGPLv3. Odoo is not licence-free

Related links

• Webinar recording: Get to know Odoo customization
• Blog post: what we wanted to get across in the customization webinar
• OCA/server-tools — the repository holding attachment_delete_restrict