Simplified Access and Permission Management for Dolibarr

Decide from a single place what each user can see and do in Dolibarr: close off entire areas or specific pages, forbid creating, editing, deleting or validating, limit which records are accessible by condition, hide or lock fields, hide tabs, columns and buttons, switch an account to read-only or suspend a login. Every refusal is decided on the server, before the page runs. A simulator shows in advance what a user will be able to do, and a log keeps every refused attempt. 

Who is it for? Dolibarr administrators, IT managers, executives and integration firms: any organization that wants to open Dolibarr widely to its teams without exposing accounting, purchase prices, colleagues' records or configuration — and that wants to be able to prove it.

Profiles, not checkboxes

• An access profile groups restrictions together and is assigned to users and groups: arrivals and departures only need a group change.
• A user can receive several profiles: their restrictions add up, they don't replace one another.
• Each profile carries its own denial message, icon, color and priority, and is created disabled until it has been checked.
• The module never writes to the permissions set in Users and Groups: it applies its rules on top, and removing a profile immediately restores the original behavior.
• The number of users actually affected, groups included, is shown on the profile's card.

16 global switches

• Read-only account: the user views everything they're entitled to, but can no longer create, edit, delete, validate or send anything.
• Suspend login: the account is disconnected immediately, without touching its Dolibarr record.
• Block configuration, exports, imports, mass actions, documents and printing.
• Hide the search bar, creation buttons, side-column tools, notes, events, documents and linked objects.
• Restrict to one's own records and, in multi-company setups, to one's own entity.
• Each switch works everywhere in Dolibarr, with no rule to write.

8 rule types

• Area: closes off a whole section of Dolibarr and removes its menu. 19 areas in the catalog, from third parties to accounting, from stock to users.
• Page: closes a specific page or an entire branch, with a wildcard for sub-pages.
• Operation: forbids create, edit, delete, validate and close, duplicate, send by email, generate a document, collect payment, import or export, on any of the 17 objects in the catalog.
• Record, field, tab, column and interface element round out the set.
• Everything is chosen from lists drawn from the catalog: no syntax to learn, no code to write.
• Each rule can be disabled without being deleted, and carries its own message.

Limit which cards are accessible

• A record rule decides which cards a user can reach, within an area that otherwise stays open to them.
• Eight conditions: they are the author, the third party is one of theirs, they are the third party's sales rep, they are a contact on the card, the status is or isn't in a list, the card is less than or more than N days old.
• The check happens the moment Dolibarr opens the card: knowing its address isn't enough to see it.
• For each rule, the simulator shows how many cards remain accessible out of the total.
• A sales rep sees only their own customers, an intern only recent invoices, an auditor only closed entries.

Fields, tabs and columns

• On a field: hide it, lock it, make it required, remove the link to the related card, or remove the create option from the drop-down list.
• The list of fields offered is read from the object itself, extra fields included: nothing to guess or type.
• A hidden field is also hidden in the list column of the same name.
• A hidden or locked field is rejected if it comes back in a request: its value can't be changed through another path.
• Hide tabs (contacts, notes, documents, events, margins, prices, bank accounts…), list columns, and 17 interface elements: create and delete buttons, action bar, mass actions, search bar, exports, printing, linked objects, bookmarks, global search…

Safe by design

• The refusals that matter — blocked page, forbidden operation, out-of-scope card, protected field — are decided on the server before the page executes, whether triggered by a click or a hand-crafted address.
• Display rules make the screen consistent with what's allowed; the operation behind each one is refused by the server.
• A Dolibarr administrator is never restricted as long as the corresponding setting stays disabled: an installation can't lock itself out.
• The module's own pages are never blocked: you can always go back and fix a rule.
• The Suspend all profiles switch lifts every restriction at once, without deleting anything.
• The module's 7 permissions are separated: view, create, delete, assign, simulate, view the log, configure.

Simulator, log and templates

• Simulator: for a given user, the profiles applied, the active switches, the blocked areas and pages, the forbidden operations, the rules on records and fields, and what's hidden — all on one screen.
• Page test: enter a path and an operation, get the answer the server would give that user, with the reason for refusal.
• Log of denied access: date, user, rule type, page, operation, message and IP address, filterable by user and by type. The first thing to open when someone complains.
• 5 ready-to-copy templates: read-only, sales rep, accountant, warehouse operator, temporary account.
• Configurable log retention period, purging of old lines, and reinstalling templates from the maintenance screen.

Technical information

• No module required: the catalog of areas and objects adapts to the modules enabled.
• Compatible with Dolibarr 16 and above (tested on 23.x), PHP 7.4 to 8.4, MySQL/MariaDB, multi-company.
• Installed through the standard module repository, no changes to Dolibarr's core.
• 5 languages: French, English, Spanish, German, Italian. PDF documentation included, NextGestion support.

Demo of the Access Manager module
Login : demo
Password : demo