# User Access Management & Access Rights Manager > Grant access by named role instead of by guesswork, copy one user's rights to another, hide the menus, fields, buttons, tabs and reports a role should not see - no code - and get told exactly which rule blocked someone. - **What it is:** Grant access by named role instead of by guesswork, copy one user's rights to another, hide the menus, fields, buttons, tabs and reports a role should not see - no code - and get told exactly which rule blocked someone. - **For:** Extra Tools - **Odoo versions:** 16.0, 17.0, 18.0, 19.0, 20.0 - Community and Enterprise - **Runs on:** Odoo.sh or Odoo you host yourself - not Odoo Online, which accepts no third-party apps - **Price:** 229 EUR, one-time, on the Odoo Apps Store - **Technical name:** bambooforge_access_manager - **Compared with the alternatives:** https://docs.bambooforge.dev/bambooforge_access_manager/compare/ - **Manual:** https://docs.bambooforge.dev/bambooforge_access_manager/ - **Live demo:** https://demo20.bambooforge.dev/odoo/action-bambooforge_access_manager.action_bf_access_role - **Store page:** https://apps.odoo.com/apps/modules/20.0/bambooforge_access_manager - **Manual last updated:** 2026-10-15 --- # 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 1. Install **BambooForge Access Rights Manager** (depends on `base` only). 2. 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 every change to a user's groups: who was changed, who changed them, how, and the exact groups added and removed. A change made through this module's wizards says which (role, copy, bulk) and names the role or source user involved. Since 1.1 a change made anywhere else that writes the user - the Users form, RPC, a script, another module - is logged too, as "Edited outside the wizards", unless the module names its own road (an access review decision, a time-boxed grant ending). Nobody can edit or delete a line. Three roads stay outside it: a user created with groups already set, groups changed from the group's side (its Users tab, or a group made to imply another) and SQL run on the database. It is a log of users' rights, not an audit of the whole database. ## Interface restrictions *Access Manager -> Interface Restrictions* Groups decide what a user **may** do. This decides what a user **sees**. The two are kept apart on purpose, and the difference is stated on every screen of it: a hidden field is not a secret, it is a tidier screen for somebody whose job never touches it. A rule names **who** and **what**. **Who** - any mix of: - *Roles* - every user holding every group of the role; - *Groups* - every user in any of them; - *Users* - named one by one; - *Except* - users the rule never touches, whatever their groups. The superuser is never restricted, so an administrator cannot lock the database. **What** - one tab each: - **Menus** - a hidden menu takes every menu under it along, apps included. - **Fields** - *Hidden* fields leave every form, list, kanban and search view the user opens, embedded lists and kanbans included, and are refused on export. *Read-only* fields stay visible and cannot be edited on screen. - **Buttons, tabs, blocks** - a button (by its method or action name), a notebook tab (by name or title), any named block, or the chatter. Press **Pick from a view**, choose the model and the view, read it, tick the ones to hide: no XML to read. - **Actions & reports** - entries removed from the Action and Print menus of their model. - **Per-model switches** - no create, no edit, no delete, no duplicate, no export, no import, or the whole model read-only. **What is enforced where.** Menus, fields, buttons, tabs and the create / edit / delete switches shape the screen. A user who knows the model name can still reach the record over RPC with whatever their groups allow - use groups for that, and *Explain access* to check them. Three switches are refused on the server as well, because they are the roads a screen cannot close: **export** (of a locked model, or of any hidden field), **import** and **duplicate**. **See it as a user** (*Tools*, or the button on the rule) answers the question every administrator asks after saving: what does this person actually see now? Pick the user and, optionally, a model: the rules that reach them, the menus gone, and per model the fields, elements and switches in force. Rules take effect the moment they are saved, for every user, without a restart; the next screen the user opens is the restricted one. Menus refresh on the user's next page load. ## 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**** The log sees changes made to a user: the wizards, the Users form, RPC, another module. A user created with groups already set, groups changed from the group's own form and SQL run on the database leave no line. ****A hidden field is still in the export dialog**** The dialog lists what the model has; the export itself is refused for a hidden field. Hide the export entirely with the model switch. ****A user still sees the menu after the rule was saved**** Menus are loaded once per page; the user reloads the page. ****The administrator cannot see something either**** Administrators are ordinary users to a rule that names their group. Put them in *Except*, or write the rule against a role instead of against a group every administrator happens to hold. ## 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*. ## How we make sure it works Before every release, **78 automated checks** run against this app on Odoo 16, 17, 18, 19 and 20. Among them: - Explain refuses an id that does not exist. - Explain survives a domain that cannot be parsed. - Explain reports a restriction it cannot evaluate. - Log cannot be edited or deleted. - Preview says what the user does not see. The complete list is in the source you receive. ## Support [support@bambooforge.dev](mailto:support@bambooforge.dev) — questions, bug reports and feature requests are answered by the developers who wrote the module. ## 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. ## What changed in 1.4 - **Interface restrictions.** Hide menus, fields, buttons, tabs, blocks, the chatter, Action and Print entries per role, group or user; make fields or whole models read-only; switch off create, edit, delete, duplicate, export and import. Elements are picked from the view, not typed. Export, import and duplicate are refused on the server as well. - **See it as a user.** The screen as one person will find it, in words, before they open it.