AccountedPro - Fields and child tables
Once a door opens a row, two more layers decide what is seen inside it: field access and child-table row visibility. Both are enforced on the server — values are removed from the payload before it leaves, so hiding is real, not cosmetic.
The six field levels
From most-hidden to most-visible:
| Level | The person sees | Can edit? |
|---|---|---|
| Hidden | nothing — the field is removed | no |
| Blur | the field is blanked server-side + visually blurred | no |
| Masked | a partial value — first/last N characters, the rest •••• |
no |
| Read-only | the real value | no |
| Editable | the real value | yes |
| Show | the real value — an explicit exception that beats a hard cap | yes |
Field access comes from two places, merged (a per-door rule beats the profile default): the Access Profile (a default for every field + per-field rules), and per-door field rules. With Best access wins resolution, a field lands at its most-visible level from any opening door — except under a hard cap.
Partial masks
For a Masked field you set show first N and/or show last N characters:
show last = 4on3736708417→••••••8417show first = 2onAB123456→AB••••••
The real value never reaches the client; on save the server re-hydrates the true value so the mask can't overwrite it.
The Blurred hard cap
A profile whose default field access is Blur or Hidden is a hard cap: the door hides/limits everything, and per-field rules may only make a field more hidden — they cannot reveal it. The one exception is the Show level, which stays visible.
A Blurred door means “you may know this record exists, but not its contents — request access for more.” After a request is approved, the cap lifts and the door's field rules define the granted view. So on a Blurred door you author the rules that describe what an approved user will then see; until approval everything is blurred, and fields you didn't write a rule for stay blurred even after approval (a grant reveals only what you scoped). The same applies to child tables — every child table is fully blurred until a grant.
Custom banner (with Jinja)
Each door can carry a custom message shown to restricted users. It supports Jinja rendered against the document, e.g. This case was last modified {{ doc.modified }} or Today is {{ frappe.utils.get_today() }}. It appears in the “Limited access” banner alongside an auto summary (read-only / some fields blurred / some rows hidden) and, when enabled, a Request Full Access button.
Per-row child-table visibility
Beyond field levels, a door can hide or blur specific rows of a child table — enforced server-side, with the hidden data re-hydrated on save so nothing is lost.
In the builder: Hide child-table rows → Add child-table rule:
| Setting | Effect |
|---|---|
| Child table | Which table (e.g. items) |
| Scope | Which rows are visible (a chip tree evaluated per child row). Rows that don't match are hidden. An empty scope means “hide every row” |
| Treatment | Blur (keep the row count, mask cells — mandatory cells get a •••••• token so Save still passes) or Hide (remove the rows) |
| Mask fields / mode | For Blur: mask only the listed fields, or all except them |
Because non-matching child rows are masked/removed server-side, they don't leak through the form, the REST payload, or a naive report — and a file referenced only by a hidden child row is blocked too (see Enforcement and security).
Read-only means read-only
When a door grants no write, the whole form is locked — not just the Save button. The submit/cancel/amend buttons the profile doesn't grant are suppressed (the server rejects the action regardless; this just removes the misleading button), and print/email entry points are removed when the door blocks them.
Next: Cascade and link guards.