The goal is not to fix everything

Some Odoo problems you can solve yourself. Some need a developer.

The valuable skill is telling them apart quickly, and gathering the right information before escalating. A well-described problem is often fixed in minutes. A vague one costs a day of back-and-forth.

This article is about narrowing things down, not about writing code.

Start with four questions

Before touching anything, answer these. They eliminate most of the possibilities.

What exactly happens?

Not “it does not work”. What did you click, and what appeared?

Get the exact message. If there is an error popup, click Show Details and screenshot the whole thing. The technical detail underneath is what identifies the problem.

Does it happen every time?

Try it again. Then try it on a different record.

Same error every time — a configuration or code problem.

Only on one record — a data problem with that record.

Intermittent — harder, and worth noting exactly when it does and does not happen.

Does it happen for everyone?

Ask a colleague to try it.

Only you — often permissions, or your browser.

Everyone — configuration or code.

What changed recently?

This is the most valuable question in the article.

A module installed. An upgrade. A settings change. A large import. Something a colleague configured.

Odoo rarely breaks on its own. If something worked last week and does not now, something changed — and identifying it usually identifies the problem.

Isolating it

Four quick tests that narrow things further.

Try a different record

If it works on one and fails on another, it is data. Compare the two — a missing value, a different configuration, an unusual character.

Try a different browser

Or a private window. Rules out a cached file or a browser extension.

Try a different user

Rules permissions in or out.

Check the browser console

Press F12 and look at the Console tab. There is often a message there that never reached the screen — particularly for blank pages and spinning loaders.

You do not need to understand it. Screenshot it and include it when you escalate.

What the message usually means

Most Odoo errors are protections, and the message says what is missing.

“You cannot delete this record” — other records point at it. Archive instead.

“No journal found” / “No account configured” — a configuration was half-completed. The message usually names the model. Ask your accountant which account belongs there.

“Not enough stock” — check the location, check reservations, check whether the receipt was validated, then check whether the count is simply wrong.

“You cannot edit a posted entry” — issue a credit note. This is how accounting works.

Permission errors — either you should have access and do not, or the restriction is correct. Find out which before making anyone an administrator.

A Python traceback — a long block of file paths and code. This is for your developer. Send the whole thing.

Handle yourself or escalate

Handle yourself:

• Missing configuration where the message names what is missing
• Permission questions
• Stock discrepancies
• Data problems on a single record
• Anything with a clear message and an obvious fix

Escalate:

• Any Python traceback
• Anything that appeared after a module install or upgrade
• Anything affecting all users
• Anything touching accounting you cannot explain
• Anything intermittent that you cannot pin down

What to send when you escalate

Six things. Sending all six usually gets it fixed the same day.

The exact error, with Show Details expanded, as a screenshot.

What you were doing — which screen, which button, which record.

Steps to reproduce — so somebody else can see it.

What changed recently — module, upgrade, import, settings.

Who it affects — one user, one role, everyone.

When it started.

The fourth is the one most often omitted and most often the answer.

The log file

Your developer will ask for this. Worth knowing what it is.

Odoo writes a log of what the server does, including full details of errors that users see only a summary of.

On Odoo.sh it is in the Logs tab of the branch.

Self-hosted, it is a file on the server — your technical partner knows where.

What is useful: the lines from around the time the error happened. Not the whole file.

After an upgrade

A special case, because the causes are predictable.

Broken inherited views. A custom view points at a field Odoo moved or renamed. Common, and usually quick.

Custom modules failing. Written against the previous version’s structure.

Integrations failing silently. Built against field names that changed. Nobody notices for weeks, because they fail quietly rather than loudly.

If problems appeared after an upgrade, say so immediately. It changes where somebody looks first.

Preventing most of them

Five habits.

Test on staging before production. Most errors surface there first, where they are cheap.

Run a full test cycle before go-live. Sales, purchase, stock, invoice, payment. Configuration gaps appear here.

Keep customisation in modules, not core files. Prevents most post-upgrade problems.

Document what integrations exist and who owns them. Silent failures need somebody watching.

Review after any module install. Two modules changing the same screen is a common and quick fix, if you know to look.

The short version

Most problems are narrowed down by four questions: what exactly happens, is it every time, is it everyone, and what changed.

Most error messages are protections, and they say what is missing.

Send the full message with Show Details expanded, plus what changed recently. Those two together identify most problems immediately — and a well-described problem is usually a same-day fix.