AccountedPro - Advanced Permission
Advanced Permission replaces role-and-permlevel access control with a no-code engine you configure per DocType — which rows a person sees, which fields inside them, what they can do, and how access propagates — enforced identically across the Desk, the REST API and MCP.
Where Frappe's native permissions stop at role → DocType → permlevel, Advanced Permission lets you say, in a visual builder:
A Receivable User may read a Sales Invoice only if its customer has an outstanding balance — and even then, blur the cost fields and hide the timeline. Everyone else must request access, which auto-approves for their own department and expires in seven days.
Every decision is made on the server. The bundled client script only makes the screen match what the server already returned — it never grants anything.
What you get
| Row scopes | A visual AND/OR/NOT builder decides which records a door opens — by field, owner, reporting line, department, age, a linked record, or “I can access the linked doc”. |
| Six field levels | Per field: Hidden, Blur, Masked (show first/last N), Read-only, Editable, or Show. Values are removed on the server, so hiding is real. |
| Per-row child tables | Blur cells or drop rows of a child table for the rows a person may not see — restored on save, so nothing is lost. |
| Relationship scopes | Reports-to subtree, department, junction EXISTS, and dynamic-link “has access to the linked doc” at a chosen permission level. |
| Access requests | A restricted user can request more; requests route to approvers, can auto-approve by rule, and expire. |
| Route guards | Blocks the paths that bypass has_permission — file download, print / PDF, and email. |
| Anti-scraping + audit | Per-window read/export caps, and an access log of who did what. |
| A simulator | “What can this user see, and why?” — the row condition, the counts, and the opening doors for one record. |
Switching it on
Installing the app changes nothing. A DocType with no enabled Access Rule is completely un-governed — Frappe's native permissions apply unchanged.
- Open the Access Rule Builder (
/app/access-builder) and pick a DocType — saySales Invoice. - Choose Default Deny: off means the app only adds access (native perms still apply where it has no opinion); on means “hide everything unless a door opens”.
- Add a door — the roles it applies to, an Access Profile (what they can do), and a scope (which rows).
- Save, then open the Access Simulator (
/app/access-simulator) to see exactly what a test user gets.
The whole loop is build → save → simulate. Turning off a rule (untick Enabled) restores native behaviour immediately — the escape hatch, and nothing is lost.
Where things live
| Where | Holds |
|---|---|
Access Rule Builder (/app/access-builder) |
The visual editor: doors, scopes, field rules, cascade, guards, request policy |
Access Simulator (/app/access-simulator) |
Row condition, visible/total counts, and per-record opening doors + actions + field access |
| Access Rule / Access Profile | The stored configuration — one rule per governed DocType; reusable profiles |
Three words that are easy to confuse
| Is | Decides | |
|---|---|---|
| Access Rule | One per governed DocType | Whether the app governs it, and how its doors combine |
| Door | A single grant inside a rule | Who (roles) × which rows (scope) × what they can do (profile) |
| Access Profile | A reusable bundle | The actions (read/write/…) and the default field access a door grants |
Enforced everywhere
Enforcement hooks the server document lifecycle, not the browser — so the same decision applies whether a record is reached through the Desk, the REST API, or an MCP connector. Lists are filtered by permission_query_conditions; single documents by has_permission; field and child-row redaction runs on the read path; and the file, print and email routes — which bypass has_permission in Frappe — are guarded at the request layer. Both permission hooks fail safe: a bug is logged and lists fail closed while single-doc checks defer to native — it can never silently leak data.
The pages
Using it
- Concepts — Access Rules, doors, profiles, door resolution, Default Deny
- Row scopes — the scope builder: every chip and operator, tokens, linked-record and has-access
- Fields and child tables — the six field levels, partial masks, the Blurred hard cap, per-row child visibility
- Cascade and link guards — Gate / Grant / Inherit, and blocking links to records you can't see
- Access requests — requesting access, routing, auto-approve, expiry
- Recipes — copy-paste patterns for common requirements
Reference
- Enforcement and security — how it's enforced across Desk / REST / MCP, the route guards, throttle and audit
- The Access Simulator — answering “why can / can't they…”, and troubleshooting
- Developer reference — the whitelisted API,
readable_rows, and the DocTypes behind it