Everything hangs off a role — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever has to answer “why can she do that and I can’t”, and would rather answer it in thirty seconds than an afternoon. In about twelve minutes you will be able to walk the chain in both directions and know which links in it are load-bearing.

Step 1 — Walk the chain once, in the direction the server walks it

After this step you will know where to start looking. When the server decides whether you may do something, it first works out who you count as: your own login, the groups you belong to, the roles you hold, and the roles reached through those groups. Then it looks for grants attached to any of them. That is the whole assignee model, and the practical reading is that four different things can be the reason somebody has access — so “she is not in that team” is never a complete answer. Across the live estate, almost all grants are attached to roles; grants pinned directly to a login exist everywhere but are a rounding error by volume.

Reference: Tenant Admin Applet — Lifecycle and effects

Step 2 — Accept that there is no way to take something away

After this step you will design roles differently. A permission is grant-only. There is no deny that overrides a grant, anywhere in the model, on either of the two permission systems. So you cannot give a team a role and then subtract one capability from one member of it: you take the capability off everybody and hand it back to the people who should have it. This is why role design in BigLedger works better from the bottom up — start from the smallest useful role and add, rather than cloning the manager’s role and trying to trim it. A trimmed clone is the single most common cause of somebody quietly holding more than intended.

Reference: Settings and Permissions — What a client-side permission actually does

Step 3 — Notice which of the two permission systems you are in

After this step you will stop granting things in the wrong place. There are two, and they are not alternatives. Server-side permissions are what the API checks; they are the ones that can refuse a request, and they are the ones with company, branch and location targets. Client-side permissions are a separate registry, per applet, and they only ever un-hide a control in the browser. The screens read the client-side list, and that list is assembled from the roles you hold, for the applet you are currently in. Two consequences: a client-side grant that is not on a role never reaches a screen, and the same code granted in Sales Invoice does nothing in Sales Order.

Reference: Sales Invoice (Internal) — Who can change what

Step 4 — Learn to spot a grant that grants nothing

After this step you will be less trusting of a tick box. The role-to-pricing-scheme link is the example worth carrying around, because it looks like a miniature permission system of its own: every row offers Sales Price Read, Sales Price Update, Purchase Price Read and Purchase Price Update. The screen writes all four, and nothing reads any of them — the till sends only the list of schemes the role may sell at. Untick Sales Price Update and that role’s cashiers can still change the price. The lesson generalises: before you build a control around a tick box, satisfy yourself that something consumes it, and the applet’s reference page is where we say which ones do.

Reference: Setting Up Pricing Schemes — Step 3: Say which scheme each applet sells at

Step 5 — Know what leaves no trace

After this step you will keep your own record. The applet audit trail is genuinely good on documents and on applet installs: who, when, the old value and the new one. It records nothing about roles, permission sets or user-to-role links. So the question “who gave her that role in March” has no answer inside the product. This is the one place where a spreadsheet is not a sign of failure: keep a change log of who holds which role and why, review it quarterly, and note the date. Fifteen minutes a quarter, and it is exactly the evidence a data-protection review asks for.

Reference: Tenant Admin Applet — Lifecycle and effects

Step 6 — Check what a person actually holds, not what you meant to give

After this step you will have a habit worth more than any diagram. The team screen has a List permissions view that shows what the linked roles really confer, and the roles listing shows how many users and how many teams hold each role. Read both after every change, because a role that looked right on paper often is not — especially one built by copying another. Then do the thirty-second version of the real test: sign in as one ordinary member, open the thing they should not be able to open, and watch. That is the only check that is looking at the product rather than at your intention.

Reference: Teams and Permissions — Step 3: Split view, edit and export

How the steps fit together

    flowchart TD
  s1["Step 1 — Walk the chain once, in the direction the server walks it"]
  s2["Step 2 — Accept that there is no way to take something away"]
  s3["Step 3 — Notice which of the two permission systems you are in"]
  s4["Step 4 — Learn to spot a grant that grants nothing"]
  s5["Step 5 — Know what leaves no trace"]
  s6["Step 6 — Check what a person actually holds, not what you meant to give"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Hiding a column is not withholding a number · Back to the series · Play this as a presentation