Screens are defined, not drawn
In many systems a screen is designed in a visual editor and saved as a picture of itself.
In Odoo, a screen is described in a file. The file says: show this field here, put these three in a group, add this tab, show this button when the record is in this state.
That description is written in XML — a structured text format. When you see a form in Odoo, you are seeing a rendered version of that description.
Why this matters to you even if you never open one: it explains why some changes are quick, why some are not, and why changes survive upgrades.
What a view definition contains
Three kinds of thing.
Structure. Groups, tabs, sections, columns. How the screen is laid out.
Fields. Which fields appear, in what order, with what labels.
Conditions. When things appear. A field visible only when a checkbox is ticked. A button shown only in a particular state. A field read-only after confirmation.
That third one is the useful part. A large share of what feels like custom logic is actually a condition in a view — “hide this unless that is set” needs no code at all.
FIGURE 1: WHAT A VIEW DEFINITION HOLDS
Structure
- Groups, tabs and columns. How the screen is arranged.
Fields
- Which ones appear, in what order, with what labels.
Conditions
- When something shows, hides, or becomes read-only.
Inheritance
The single most important concept here, and it is the reason Odoo upgrades work.
When a module needs to change a screen, it does not copy the whole definition and edit the copy. It writes an instruction: find this field in the existing view, and put my new field after it.
Your change is a patch applied on top, not a replacement.
Two consequences:
Upgrades work. Odoo improves the standard form; your instruction is re-applied on top. You get the improvements and keep your changes.
Several modules can change the same screen without conflicting, as long as their instructions do not target the same thing.
And the failure mode: if Odoo removes or renames the field your instruction points at, the instruction cannot find its anchor and the view breaks. This is one of the most common things that needs fixing at an upgrade — and it is usually quick.
FIGURE 2: WHY VIEW CHANGES SURVIVE UPGRADES
Inherited view
- An instruction — “put my field after this one”
- Re-applied on top of the new version
- Breaks only if the anchor field disappears
- Several modules can coexist
Replaced view
- A full copy of the original, edited
- Odoo’s improvements are lost
- Diverges further with every version
- Nobody can tell what changed
Why some requests are quick and some are not
Knowing the shape of a view definition explains estimates.
Quick. Moving a field. Changing a label. Adding an existing field to a form or a list. Hiding a field under a condition. Reordering columns.
These are edits to the view description. Nothing else changes.
Not quick. Adding a field that does not exist — that changes the model, and it may need logic behind it. Changing what a button does. Anything where the layout needs data that is not there.
A useful question when you ask for a change: does this information already exist somewhere in Odoo? If yes, it is usually a view change. If no, it is a bigger piece of work.
Studio and XML
Odoo Studio edits views by dragging. Under it, Studio is writing the same inherited view definitions.
So Studio changes are XML changes — made by clicking rather than by typing.
The difference is not the result. It is the record. A developer’s change lives in a module with a history: who made it, when, and why. A Studio change has none of that.
For moving a field, that hardly matters. For thirty accumulated changes over two years, it matters a great deal — because eventually somebody has to work out what was changed and why, with nothing to read.
When views break
Three common causes, and what each means.
After an upgrade. An inherited view points at a field Odoo moved or renamed. Usually a quick fix once identified.
After installing a module. Two modules trying to change the same part of a screen. Also usually quick.
A field referenced that no longer exists. Often after a module was uninstalled, taking its fields with it.
What to send when reporting one: the exact error message, which screen, and what changed recently. That third item is usually the answer.
FIGURE 3: WHAT TO SEND WHEN A SCREEN BREAKS
The exact message
- A screenshot of the full error, not a description.
Which screen and which record
- So it can be reproduced.
What changed recently
- A module, an upgrade, a Studio edit. Usually this is the answer.
What good practice looks like
If you commission Odoo work, four things worth expecting.
Changes are inherited, not replacements. Ask directly. A partner replacing whole views is storing up upgrade problems.
Custom views live in modules, under version control, not scattered across Studio.
Studio use is logged. If Studio is used, somebody keeps a written note of what and why.
Views are tested at upgrades. Broken inherited views are one of the most common upgrade issues, and testing catches them before users do.
Asking for a view change
Be specific about three things and you will get what you wanted:
What information. “The customer’s PO number.”
Where. “On the invoice form, next to the invoice date.”
When. “Only when the customer is a business, not for walk-ins.”
That is enough to build from. “Make the invoice screen better” is not, and it produces a meeting rather than a change.
The short version
Odoo screens are descriptions in files, not drawings. That is why they can be patched by modules and why changes survive upgrades.
Inheritance is the key idea — a change is an instruction applied on top, not a copy.
Moving and hiding existing fields is quick. Adding information that does not exist is a bigger piece of work.
And when you ask for a change, say what, where, and under what condition. Three sentences saves a meeting.
Need screens that match how your team actually works?
Get in touch. Most layout changes are quicker than people expect — tell us what you want to see and where.
