Configuration
Every setting in Access X-Ray, and what each one changes.
Access X-Ray is deliberately close to configuration-free. There is no setup wizard, no credentials, no scheduled job and no settings page — because a read-only analysis tool that needs configuring before it can answer a question has already failed at the thing it is for.
What can be adjusted is listed here.
Who can use it
Every model in the module is restricted to base.group_system — Odoo's Settings group. There is no viewer role and no second tier.
This is a decision, not an omission. The tool's whole output is a map of who can reach what, and that map is precisely the reconnaissance an attacker or a disgruntled insider would want. Handing it to a wider audience than the people who already administer the system would create the risk the product exists to find. See SECURITY.md.
To grant access: Settings → Users → the user → Administration: Settings.
Dormant threshold
Where: the Run Scan action, before running. Default: 90 days.
The number of days without a login after which an account counts as dormant for the Dormant with access finding.
90 is the common internal-audit threshold. It is exposed on the scan rather than hard-coded so an organisation that reviews quarterly can move it to match their own cycle, instead of arguing with a number they cannot change.
Sensitive models
Where: models/access_finding.py, SENSITIVE_MODELS. Used by: the Delete rights on sensitive models finding, and the Only sensitive models filter on the By User probe.
| Model | Why it is on the list |
|---|---|
| account.move | Journal entries and invoices |
| account.move.line | The lines that carry the amounts |
| account.payment | Payments |
| account.journal | Where entries are posted |
| res.partner.bank | Bank account details — the classic quiet change that moves money |
| hr.payslip | Payslips |
| hr.contract | Contracts, including salary |
| res.users | Accounts |
| res.groups | Group membership |
| ir.model.access | The access rules themselves |
| ir.rule | The record rules themselves |
The list is deliberately conservative. A list long enough to flag everything flags nothing, because the reader stops reading. Eleven models fit on a screen and every one of them is defensible in a conversation with an auditor.
If your business has a model that belongs on this list — a custom approval model, a pricing model — it can be added, but treat additions the way you would treat adding a line to a control framework: each one costs a little of the list's credibility.
What is not configurable, and why
| Not configurable | Reason |
|---|---|
| Whether the module can write to users, groups or rules | It cannot, by design. There is an automated test asserting it. |
| Whether findings are sent anywhere | Nothing leaves the instance. There is no outbound connection to configure. |
| A scheduled scan | Scans are run deliberately, by a person, when they want the answer. A cron job producing findings nobody reads is worse than no findings. |
| Field-level access | Not resolved in this version — see FAQ.md. |