Troubleshooting
What goes wrong with Access X-Ray, how to recognise it, and what to do.
The Access X-Ray menu is not visible
The account is not in the Settings group. Every model in the module is restricted to base.group_system — see SECURITY.md for why.
Settings → Users → the user → Administration: Settings.
A user's report says "this account bypasses access control" instead of listing permissions
That is correct behaviour, not a failure. The account is either the superuser or holds the Settings group, and both bypass access control entirely. A permission list for such an account would be misleading: it would imply limits that do not exist. The honest answer is "everything", and that is what is shown.
Someone still has a permission after I removed their group
Model access is a union and there is no deny. If two groups grant the same right, removing one leaves the other.
Look at the Granted by column on the By User probe: it names every granting group, not just the first. That is what the column is for.
Adding a group made a user see more records, not fewer
Expected. Global record rules AND — they always narrow. Group record rules OR — each additional group rule adds an alternative path to a record.
So adding a group can widen visibility while reading like a tightening. The probe keeps global and group rules in separate columns for exactly this reason.
A user can read a model but cannot see a field on it
Field-level groups= attributes are not resolved in this version. Model access rules, record rules and group inheritance are. This is a known and stated limitation, not a bug — see FAQ.md.
The scan is slow, or times out
A scan is bounded by the number of users, groups and access rules — not by the volume of business data. On a database with thousands of user accounts and a deep group hierarchy it can take longer than a page-load timeout.
If that happens:
- Run it during a quiet period.
- If your deployment sits behind a proxy with a short timeout, raise it for that request, or run the scan from a shell:
odoo-bin shell -d YOUR_DATABASE
>>> env["access.finding"].run_scan()
>>> env.cr.commit()The dormant finding names accounts that are in use
The dormancy threshold is based on last login, and 90 days is the default. Accounts used only through the API, or shared accounts logged in once and kept open, can look dormant.
Raise the threshold on the scan, or treat the finding as it is meant to be treated: a list to explain, not a list to delete.
Findings from a previous scan are still showing
They are not — a scan replaces the previous findings rather than adding to them, and there is a test asserting it. If the list looks stale, the scan has not been re-run since the change you are looking for.
Nothing appears after installing
The module ships no findings. Run Scan produces them. The Explore probes work immediately without a scan.
Uninstalling — will it change our permissions?
No. Uninstalling removes the module's own tables and nothing else. It never wrote to res.users, res.groups, ir.model.access or ir.rule, so there is nothing of ours to unwind.
Still stuck
info@technovision.dev — include your Odoo version, edition, and what the report said versus what you expected. There is no log to send: the module makes no external calls and writes no log file of its own.