9.1 Studio: custom fields, views, models & reports

Odoo Studio: no-code customization

Odoo Studio is the built-in toolkit that lets a functional consultant tailor the system without writing Python or XML. It is an Enterprise-only application: once the Studio app is installed, a Toggle Studio button — the wand-and-pencil icon — appears in the top control panel of every screen. Clicking it opens whatever view you are looking at in edit mode, where you drag elements from a side panel onto the record. Everything Studio produces is stored as ordinary Odoo configuration (fields, views, actions, reports), so the certification tests what Studio can do and the conventions it follows, not how to program.

Adding custom fields

The most common Studio task is adding a custom field. From the "Add" tab you drag a field type onto a form; Studio creates the database column automatically and gives it a technical name prefixed with x_studio_. Picking the correct field type is a recurring exam theme:

After dropping a field you configure its properties in the panel: the visible label, whether it is Required, Read-only, or Invisible, a default value, a help tooltip, and a widget that changes how the value is displayed (a Selection shown as a badge, a Many2many shown as tags, a number shown as a progress bar). Conditional logic is handled with a domain: a field can stay invisible until another field holds a certain value, or become required only in a particular state — all without code. Studio can also add computed and related fields whose values are derived from other data, and default or onchange behavior, so much of the logic a developer would once write is now configured by choosing options in the panel rather than editing code.

Editing views

A crucial concept is that Studio edits the view, not a single record. You can modify the form, list, kanban, calendar, pivot, graph, and activity views of the same model. On a form you drag in groups, tabs (notebooks), a status bar, and buttons; on a list you add, reorder, or hide columns and switch on inline editing. Because a view is shared, any change is seen by every user who opens that model — which is why a Studio view edit is fundamentally different from a personal filter or favorite, which affect only one user's own screen.

Creating new models and menus

Studio can build an entirely new model from the "New Model" wizard. You tick pre-built features — Chatter (messaging and logging), Pipeline stages, Tags, Notes, company restriction, Archiving, or an automatic Sequence — and Studio scaffolds the model with a technical name prefixed x_. It also manages menus: you can add a new top-level app menu with its own icon, add sub-menus beneath it, and point them at your model's views so users reach the data straight from the main navigation. This is how a consultant delivers a small bespoke application without a developer.

Custom PDF reports

Studio includes a drag-and-drop report editor for QWeb PDF documents. Starting from a blank report or an existing one — such as the sales order or the invoice — you drop in fields, tables and columns, text blocks, images, and conditional blocks that print only when a condition is met. The header, footer, and logo come from the company's document layout. This lets you add a legal clause or an extra data column to a printed invoice without editing any XML by hand.

Importing and exporting customizations

Behind the scenes, every Studio change is packaged as a custom module. From the Studio menu you can export all customizations as a downloadable ZIP and import it into another database — the standard, supported way to move work from a staging database into production. Because the output is a genuine module, it upgrades cleanly and can be tracked in version control, which is exactly why Studio changes should be built and tested outside production first, then imported once verified. Understanding this export/import path — rather than rebuilding the same changes by hand in each database — is a common exam point and reflects good deployment discipline.

Studio versus developer mode

Studio is aimed at functional users, while developer mode exposes the same fields, views, and actions as raw technical records for advanced editing. A field you create in Studio (x_studio_...) is visible in developer mode too, but you rarely need to leave Studio for standard customization. For the functional exam it is enough to know that Studio is the recommended no-code path and that its output is portable through the module export.