SERVICES/CUSTOMISATION
Odoo customisation
that survives the upgrade.
Inheritance, automated tests and a staging branch. Every change ships as a module in your own repository.
Studio
Apps
Settings
Knowledge
Spreadsheet
Documents
SERVICES/CUSTOMISATION
Odoo customisation
that survives the upgrade.
Inheritance, automated tests and a staging branch. Every change ships as a module in your own repository.
Studio
Apps
Settings
Knowledge
Spreadsheet
Documents
A MODULE OF OURS
Two fields Odoo does not have.
A role on the task and a budget that follows from it, added to Odoo's own task with inheritance. Pick the role and the money moves with it, because the field does the work.
HOW IT RUNS
Custom code is the exception, and it ships inside the rhythm.
Sprint 0
We look for the lightest answer first. Most of what gets called custom is a setting, and we say so.
In its own sprint
What really has to be built is built inside the sprint of the process it serves, not beside it.
On a branch
Inheritance, automated tests and a staging deploy. Nothing reaches production untested.
Then the lane
It sits in your own repo, written with inheritance and tests so it survives the next Odoo version.
Studio is not our advice for anything beyond a one-off field, a PDF report or an email template. Everything else is code, in a module, in your repo.
Deployment
From branch to production in minutes.
Every custom module follows the same path. Feature branch, automated tests, staging validation, then production. Rollback is one click away.
AppsStudioSettingsDocuments
Module lifecycle
circel_project_roles · v19.0.1.12.1
Design
Requirements turned into a technical blueprint
✓ Approved
Build
Inheritance, tests and access rights written in
✓ 3 tests passed
Staging
You test against your own data and sign it off
✓ UAT signed off
Production
Staging first, rollback one click away
● Deploying
OUR APPROACH
Configure first, code where it pays off.
Configuration first
- Settings, routes, journals and pricelists, which covers most of it
- Automated actions and scheduled jobs
- Access rights and record rules
- Studio, but only for a one-off field, a PDF report layout or an email template
That is where Studio stops. We do not advise it for anything beyond those three.
Everything else, as a module
- Custom fields and views your process depends on
- Complex business logic and workflows
- Integrations with external systems
- Custom reports, dashboards and performance-critical calculations
Every one of these ships as a module on your own Odoo.sh repository, with tests, a branch and a rollback.
FAQ
Straight answers.
QWhen do you use Studio instead of custom code?
AOnly for a one-off field, a PDF report layout or an email template. Anything your process depends on goes into a module in your repository, where it has tests, a review and version history.
QDo custom modules break on Odoo upgrades?
AWe use Odoo inheritance patterns and automated tests, and we run every module against the new version on staging before production moves.
QCan you maintain modules another partner built?
AYes. We audit the code, write down what we find, and take over maintenance. If the quality is poor we propose a refactor plan with a price on it.
QWhere does the code actually live?
AIn your own git repository on Odoo.sh. Feature branch, automated tests, staging validation, then production. You own it, and you can take it with you.
