Troubleshooting
What goes wrong with Restrict Delete & Export, how to recognise it, and what to do.
A rule is not being enforced
Check, in this order:
- The global switch. Settings → General Settings → Access Restrictions → Enabled. Off means nothing is enforced anywhere.
- The rule is active. Archived rules do not apply.
- The user is not bypassing. The superuser always bypasses. Settings-group users bypass while Settings users bypass is on — which is the default.
- The operation is ticked on the rule. Restricting Delete does not restrict Export.
- The route. Deletes through XML-RPC, JSON-RPC, a custom controller or raw SQL do not pass through the monitored funnel and are not blocked. This is a stated limitation, not a fault — see FAQ.md.
Everything is being blocked, including for people who should be allowed
The rule is an allow-list. Once an operation is restricted, only the listed groups and users may perform it — there is no implicit "everyone else is fine".
Add the group to Allowed groups on the rule. If a single person needs the exception and a group would be overkill, use Allowed users.
The form will not let me pick a model
Two sets of models are refused:
- This module's own — access.restriction.rule and access.restriction.attempt. Restricting them would remove your ability to lift a restriction.
- Odoo's management models, 25 of them, including res.users, res.groups, ir.model.access, ir.rule, ir.cron, ir.attachment and res.config.settings.
Both lists are Python-level guarantees, not settings, and cannot be overridden from the interface. See CONFIGURATION.md.
"At least one operation must be restricted"
A rule that restricts nothing is rejected rather than saved and silently ignored. Tick at least one of Delete, Export, Print, Archive or Duplicate — or archive the rule if you want it kept but inactive.
"A rule already exists for this model"
One rule per model, enforced by a database constraint. Edit the existing rule rather than adding a second. If you cannot find it, clear the filters — it may be archived.
Users are confused by the refusal message
That is a content problem, and it is worth fixing properly: the message is the entire user experience of this module.
Replace "Access Denied" with an instruction — "Archive the contact instead, or ask a Contact Manager if it really has to go." One generates a support ticket every time; the other generates none.
The blocked-attempts log is empty
- Logging may be off globally, or on that rule.
- Nobody may have been blocked. Check the rule is actually enforcing first, using the list above.
- Attempts older than the retention period are pruned by a cron. The default is 180 days; 0 keeps everything.
The log is very large
Lower the retention in Settings → General Settings → Access Restrictions, or turn logging off for the noisiest rule. A rule generating thousands of blocked attempts is usually a rule that is wrong — read them before deleting them.
Performance concerns after installing
The check runs on delete, copy and archiving writes only — never on reads or on ordinary edits — and is a cached lookup that returns immediately for any model without a rule.
If you are seeing a slowdown on reads, it is not this module. Confirm by switching Enabled off: if the symptom persists, look elsewhere.
After an upgrade nothing is restricted any more
Check the global Enabled switch and the retention setting first — they are ir.config_parameter entries and a deployment script that resets parameters can clear them.
Still stuck
info@technovision.dev — include your Odoo version and edition, the rule as configured, the operation attempted, and which route it came through (interface, API, custom code).