Odoo Studio Custom Fields: Export, x_studio Names and Upgrade Risk
Odoo Studio custom fields export upgrade x_studio
Also searched as
- odoo studio customizations lost after upgrade
- odoo studio export to module
- odoo x_studio fields in custom module
- odoo studio vs custom module which to use
Short answer
Odoo Studio saves your changes as data in the database: custom fields named x_studio_*, edited views stored as inherited ir.ui.view records, and automation rules. You can export them as a module via Studio's Export button, but upgrades can break Studio views when the base view changes, and Studio is not a substitute for version-controlled code on complex logic.
Applies to: Odoo Enterprise 15, 16, 17 and 18 with the Studio app (Odoo Online, Odoo.sh and on-premise Enterprise)
How to export and protect Studio changes
- 1Open Studio from any app and note which models you modified. Customizations are scoped by model, not by app.
- 2In Studio, open the three-dot or Customizations menu, choose Export, and download the zip. This creates a module containing data for the fields, views, actions and automations, with xml ids prefixed studio_customization.
- 3Review the zip: data/ir_model_fields.xml, ir_ui_view.xml and any ir_actions_server.xml. Read the views and the server actions for hard-coded ids and company-specific values.
- 4Install the exported module on a staging database to verify it recreates the fields and views without errors.
- 5Before an upgrade, take a copy of the database, run the upgrade on it, then open each customized view. Broken views raise 'Element cannot be located in parent view' errors.
- 6Fix by editing the inherited view in Settings > Technical > User Interface > Views, searching by name with Studio in it, and correcting the xpath, or by re-doing the change in Studio.
- 7For complex logic, move computed fields and automation code into a proper custom module kept in Git and stop adding it in Studio.
What Studio actually creates
A field added in Studio is a normal row in ir_model_fields with state set to manual and a technical name beginning x_studio_ (earlier versions used x_ with other prefixes). Because it is stored as a manual field, the database column is created on the model table, for example x_studio_priority on sale_order, and appears in the ORM like any field.
Views changed in Studio are saved as inherited views on top of the original, with an xpath to place or hide elements. The base view stays untouched, so the customization survives module updates until the base structure changes under the xpath.
Automations built in Studio become base.automation records with server actions, which may contain Python snippets that run on create or write. These live in the database, are not under source control, and run with the permissions defined on the action.
-- List Studio and other manual fields on a model SELECT name, field_description->>'en_US' AS label, ttype, state FROM ir_model_fields WHERE model = 'sale.order' AND state = 'manual' ORDER BY name; -- Studio views SELECT id, name, model, inherit_id, active FROM ir_ui_view WHERE name ILIKE '%studio%' AND active;
Exporting and re-importing
The Studio export module is intended to move customizations from a sandbox or staging database to production, or into a custom module you maintain. It uses xml ids tied to the customization so re-importing updates existing records rather than duplicating them.
It exports definitions, not the data held in those fields. Populate x_studio_ fields in the target database through import or the API. Exports are also limited in what they capture: reports edited in Studio, access rights and some settings may need verification after import.
Do not hand-edit the generated xml ids. Studio relies on them to recognise its own records, and rewriting them leads to duplicate fields on the next export.
What breaks at upgrade
Major version upgrades through Odoo's upgrade platform or openupgrade rewrite standard views. A Studio xpath that targets a field or group which no longer exists produces an error on loading that view, and the form becomes unusable for the model. Because customizations are layered, one broken inherited view can take down a whole screen.
Reports edited in Studio are stored as QWeb view overrides and fail in the same way when the base report template changes. Test PDFs after upgrade, not only the web forms.
Studio fields themselves usually migrate cleanly because they are plain columns. The risk is on views, reports, automations that reference removed fields or methods, and computed fields written as Python in server actions.
Studio or a custom module?
Studio is a good fit for adding a few fields, simple view layouts, approvals and light automations. It is hard to review, diff and test, and it is only available on Enterprise.
Move to a custom module when you need relational logic, computed fields with dependencies, constraints, unit tests, a CI pipeline or deployment across several databases. A common pattern is to prototype in Studio, export, then clean up the generated XML into a maintained module and uninstall the Studio customization.
Common pitfalls
- !Adding critical business logic in Studio automations with no source control or tests.
- !Skipping an upgrade rehearsal on a database copy and finding broken views in production.
- !Renaming x_studio_ fields in SQL, which breaks stored views, filters and automations that reference them by name.
- !Assuming the export carries field data, not just definitions.
- !Editing PDF reports in Studio and not retesting them after a version change.
How an ERP-grounded AI assistant handles this
An assistant that can read the ir_model_fields, ir_ui_view and base_automation tables can produce an inventory of what Studio changed, which views reference which x_studio_ fields, and which of them an upgrade is likely to affect. That makes the rehearsal faster. Generating the cleaned-up module is a drafting task with a developer reviewing it. Applying any change to production views remains a human-approved step.
Frequently asked questions
Does Odoo Studio work on Community edition?
No. Studio is an Enterprise app. Community users add fields through developer mode (Settings > Technical > Database Structure > Fields, which creates manual fields) or through a custom module.
Will Studio customizations survive an upgrade?
Fields usually do. Views, reports and automations can break if the base view changes under them. Always rehearse the upgrade on a database copy and review every customized screen before going live.
Can I rename a Studio field?
You can change the label freely. Changing the technical name x_studio_* is risky since views, filters, reports and automations refer to it. Create a new field and migrate the data instead of renaming it.
How do I move Studio changes from test to production?
Use Studio's Export on the test database, then import the generated module in production, or install it as an app. Verify the result and populate field data separately. Odoo.sh teams often commit the cleaned module to Git instead.
Related
Odoo External API: Authenticate and search_read with XML-RPC and JSON-RPC
Call the Odoo external API by authenticating against /xmlrpc/2/common to get a user id, then calling execute_kw on /xmlrpc/2/object with the database, uid, password or API key, model name, method and arguments. If authenticate returns False, the database name, login, or API key is wrong, or two-factor is enforced for that user.
Error fixFix Odoo AccessError: You Are Not Allowed to Access Records
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
Error fixOdoo Scheduled Actions (Cron) Not Running: How to Fix
Odoo scheduled actions usually stop firing because no cron worker is available (workers or max-cron-threads misconfigured), the action is set inactive, or an earlier job crashed and left an ir.cron row stuck in the running state, which blocks the queue. Check Settings > Technical > Automation > Scheduled Actions first, then the server config and the ir.cron table.
How-toHow to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
How-toHow to Run Requirements Planning (MRP) in SYSPRO
SYSPRO's MRP engine lives under Planning and Scheduling > Requirements Planning. Set planning parameters per warehouse, run the Requirements Calculation to net demand against supply, then review and release the resulting suggestions as purchase requisitions or work orders. A full regenerative run typically runs on a schedule, with net change runs in between to pick up new activity.
AI for ERPAI for Odoo Manufacturing That Reads Your Own Database, Not a Vendor's Cloud
Add grounded, natural-language AI to Odoo Manufacturing without sending MRP, BoM, or work order data to a public model. On-prem or private cloud, ORM-native.
AI for ERPAI Demand Forecasting for Manufacturers: Better Numbers and an Explanation Planners Can Trust
AI demand forecasting explains ERP forecast changes in plain language, flags exceptions for planners, and handles short-history SKUs without Excel overrides.
Stuck on Odoo Enterprise?
Talk to engineers who work inside Odoo Enterprise every week, and who build private AI that answers these questions from your own ERP data.