User Access Management & Access Rights
Grant access by named role instead of by guesswork, copy one user's rights to another, and get told exactly which rule blocked someone.
Available for Odoo 16.0, Odoo 17.0, Odoo 18.0, Odoo 19.0. Technical name bambooforge_access_manager.
User Access Management & Access Rights
Odoo's access rights are precise and unreadable. This app makes them manageable — roles instead of guesswork, a preview before anything is written, an explainer that says which rule blocked a user, and a log of every change.
This page is the complete manual.
Install
Install BambooForge Access Rights Manager (depends on base only).
The Access Manager menu appears for users in the Access Manager group, which implies Settings — the people who already manage users.
Roles
Access Manager → Roles
A role is a named bundle of groups: "Warehouse operator", "Accountant, read-only", "Field sales". Give it a description in the words the person doing the hiring uses, and put the groups in.
The role card shows how many users currently hold every group of the role, and the button opens that list — so "who is a warehouse operator?" has an answer again.
Apply to users opens the preview.
Applying, copying, bulk editing
All three tools work the same way: pick the targets, read the preview, apply. Nothing is written until you press the button, and everything that is written lands in the change log.
Apply a role — Add leaves the user's other groups alone; Replace strips everything the role does not contain. Replace is right when a role is the whole job, and dangerous otherwise: the preview shows exactly what it would take away, in red.
Copy access — the day-one task. Point at somebody who already works, copy to the new hire. Replace makes the access identical; Add only fills the gaps. The source user is skipped if they are also in the target list.
Bulk edit — add or remove a few groups across a selection of users. It is also bound to the Users list: select users, Action → Bulk access edit.
Each preview lists, per user, the groups gained in green and the groups lost in red — or says plainly that nothing changes.
Explain access
Access Manager → Tools → Explain access
The feature the "Access Error" dialog never gives you. Pick:
User — whose access is in question.
Model — what they are trying to reach.
Operation — read, write, create or delete.
Record id (optional) — the exact record, when the problem is "everything works except this one".
The verdict comes back in words:
Model access — the access-control lines that apply to this user's groups and grant the operation, named with their group. When none do, it says so, and lists the groups whose lines would grant it — which is usually the answer to "what should I give them?".
Record rules — every rule in force for this user on this model, with its scope (global, or the groups it belongs to) and its domain. With a record id, each rule is marked as allows this record or excludes this record — the one in red is the reason.
If a rule's domain cannot be parsed at all — a bad module data file, a hand-edited row — the verdict says the check could not run and points at the rule instead of failing silently.
Change log
Access Manager → Change Log records, for every change made through this module: who was changed, who changed them, how (role, copy, bulk), which role or source user was involved, and the exact groups added and removed.
Changes made elsewhere — the user form, a data file, a script — are not in this log; it is a log of what this module did, not an audit of the whole database.
Troubleshooting
- A role shows zero users though people clearly have those groups
The count is users holding every group of the role. A role with a group almost nobody has will count almost nobody.
- Replace removed more than expected
Replace leaves only the role's groups. Check the preview before applying; the change log has the exact list, so the groups can be put back.
- Explain says the user may read, but they still see an error
Check the record id: model access can be fine while a record rule excludes that one record. That is what the record-level answer is for.
- Explain says a rule "excludes this record" but the user sees it
Rules of the same group are OR-ed together in Odoo, and rules of different groups are AND-ed. The wizard reports each rule on its own; one red line among several green ones of the same group is not a block.
- Nothing appears in the change log
Only changes made through this module's wizards are logged.
What changed in 1.1
Segregation of duties. Name the pairs of groups one person must never hold together (create vendor bills / approve payments). Blocking rules refuse the grant whatever road it takes - wizards, the Users form, RPC; warning rules let it through but keep the person on the violation list. Access Manager -> SoD Rules, plus a one-click scan of everybody already in violation.
The log cannot be walked around. Group changes made outside the wizards are captured too, and the log itself became append-only - nobody edits or deletes history, deleting a user keeps their trail.
Names are escaped everywhere the wizards render previews.
What changed in 1.2
Time-boxed grants. The Apply and Bulk wizards take an optional end date: every group granted with it is revoked automatically on that day by a daily job, and the change log says the clock did it. Revoke early from Access Manager -> Time-boxed Grants.
Support
support@bambooforge.dev — questions, bug reports and feature requests are answered by the developers who wrote the module. n What changed in 1.3 ===================
The change log can be told where a change came from. Another module (the Audit Pro bridge, for one) can set bf_access_source in the context, and rights changes it makes are filed under that source instead of "edited outside the wizards" - the entry nobody can reconcile at audit time. Unknown sources still fall back to a plain direct edit, so the log cannot be spoofed into a value it does not define.
nSupportn=======n
Screens
