Odoo 19 UAT Passed as Admin, Failed for the Real User

Demos pass with full rights. Log in as the actual role and folders, templates, shifts and menus disappear. Here is how to test access before go-live.

This post covers one item from my list of 11 Odoo 19 problems from real projects. The system was not broken. The test was run with the wrong login.

What we saw

The demo went well. The user acceptance test went well too. Every step on the script passed: documents were there, the sign template was there, the shifts were there, the menu opened.

Then the real user logged in on go-live week, and half of it was gone.

They saw far fewer document folders. No sign templates. No planned shifts — the shifts existed, but they were still in draft, and that role could not see them. One menu showed in the navigation but would not open when clicked.

Nothing had been deleted. Nothing had changed since the test. The only difference was the login. The test had been run as admin. The real user had a normal role with missing groups and record rules.

Why admin hides the problem

Admin sees everything. No access group is missing, no record rule filters anything out, no draft state hides a record.

That makes admin the worst login for acceptance testing. When admin runs the script, the test answers a different question from the one you need: "does this feature exist in the system?" instead of "can this person do their job in the system?"

Most access problems I see fall into four groups:

• Missing group. The role does not have the group that gives the menu or the action. The menu either does not show, or it shows and refuses to open.
• Record rule. The user can open the screen but sees only part of the records. Folders, templates or shifts that exist are invisible to them.
• State. Records in draft or unpublished state are hidden from non-privileged roles. Admin sees drafts; the role sees only confirmed items.
• Multi-step rights. The user can start a step but cannot finish it: they can request but not submit, fill but not sign, view but not assign.

Each of these passes when admin clicks through. Each fails on the first day of real use.

Why this hurts

An access failure at go-live looks like a system failure to the team. They were trained on screens they cannot open. They were told templates exist that they cannot find. Trust drops fast, and support gets calls that sound like bugs but are really missing rights.

The fix is usually small — one group, one rule. But finding it under pressure, with users waiting, takes far longer than catching it during testing. And every quick fix granted in a hurry ("just give them manager rights for now") stays in the system and becomes the next audit problem.

How to check it before go-live

Run every acceptance script with the login of the person who will do the work, not admin. One script, one real login, from start to finish.

1. Create the test login with exactly the groups the real role will have. No extra rights "for testing".
2. Log in as that user in a private browser window, so no admin session leaks in.
3. Run the full script: open each menu, list the folders, open the sign template, check the planned shifts, submit one request end to end.
4. Where a list looks short, log in as admin in a second window and compare the count. If admin sees ten folders and the user sees three, you have found a rule or a group to fix.
5. Test the negative too: try something the role should not be able to do, and confirm it is blocked.

Two checks people skip:

• Draft records. If the process uses drafts — shifts, documents, templates — check them as the role while they are still draft, not only after approval.
• Menus that show but do not open. Click every menu the role can see. A visible menu that errors on open is a classic missing-group sign.

This is part of the wider way I plan Odoo implementation in Oman: access is tested by the person who will use it, on their own login, before the system opens.

What we do now

After meeting this on a real project, we changed the rule for testing:

• No admin acceptance. A test run as admin counts as a demo, not an acceptance. The sign-off only counts when it ran under the real role.
• One login per script. Each test script names the login it must run under. The tester logs in as that user and stays there for the whole script.
• Compare counts, not just screens. For every list — folders, templates, shifts — we note how many records the role sees and compare with what should be there. "It opened" is not enough. "It shows the right records" is the pass mark.

What to do if you are already live

If your team already works in Odoo 19 and some users report missing folders, templates or shifts:

• Ask which login the original test used. If the answer is admin, re-run the failing steps as the user's own login and note exactly what is missing.
• Check the role's groups first, then the record rules on the missing items, then whether the items are still in draft.
• Resist adding broad manager rights to close the ticket. Grant the smallest group that fixes the step, and re-test the full script as the user.

Need a second look?

If some users see less than they should in Odoo 19, or your acceptance passed but go-live did not, get in touch.