Access screens prototype
Table of Contents
| Item | Where |
|---|---|
| Prototype | the prototype |
| Gemini review | the review |
| Group | Access prototypes |
1. Summary
The access journeys had wireframes and no prototype. The wireframes draw the permissions as a flat list of codes, which the real catalogue does not survive: it holds 890 permissions in 17 areas. This prototype draws the three original access journeys on that real catalogue and on the real seeded roles, with mock people, so it is judged against the data the screens will hold.
- Know what I may do: My access, from the person's own menu.
- Change someone's access: People, then a person.
- Shape the role catalogue: Roles, then a role.
It is throwaway. It is not production code and it reads no service.
Open the access screens. A link can open one screen
directly, for example access/#persona=tenant&screen=role&role=Operations or
access/#persona=tenant&screen=requests.
2. Detail
2.1. The verdict
Accepted on 2026-10-04. The user asked how a member requests a role: the prototype does not draw it. Asking is the fourth access journey, Ask for more access, and it has no server yet (no request subject, no waiting state in the workflow engine, no notice), so it belongs to its own task in the access story and gets its own prototype there.
2.2. What it argues
| Wireframe | This prototype | Why |
|---|---|---|
| Effective permissions as a list of codes | A grid per area: what, then Read, Write and Delete, and the rare other actions beside them | 890 codes in 17 areas, and almost every one reads, writes or deletes one thing |
| The member reads the whole list | Can I…? answers a question and names the role that allows it | A member wants an answer, not a catalogue |
A role holding * lists every code |
It says Everything | Ticks for 890 codes hide the one fact that matters |
| Every role in the picker | The 19 service roles are hidden unless asked for | They belong to the platform's services, not to people |
| Add selected, Remove selected | Give a role and Take away, each with a reason | The person's words; the grant row records who, when and why |
| Save role | The save shows what it adds and removes, and who holds the role | One save changes access for everyone who holds it |
| Changes take effect on the next sign-in | Within 30 minutes, when the sign-in renews | Refresh reads the permissions again |
Every account shows its picture: in the header, the people list, a person's page, who gave a role and who holds one. The user made this a general rule on 2026-10-04, for every screen that shows an account.
Two small guards are drawn: a person cannot take their own administration away, and a role that people hold cannot be deleted.
2.3. Asking for a role
Added after the first verdict, when the user asked how a member requests a role. It draws Ask for more access:
- My access offers Ask for a role: a role the person does not hold, and why they need it. Roles that grant everything are not offered. Your requests lists each request with its state (waiting, given, refused, withdrawn), and the administrator's answer with their picture; a waiting one can be withdrawn.
- Requests, for the tenant administrator, lists what is waiting, oldest first, with a badge on the menu. A request shows who asks, why, what they hold now and what the role would let them do. Give grants the role through the ordinary grant; Refuse needs a reason the person reads. Nobody answers their own request.
The journey holds a request as a waiting workflow instance, and the workflow
engine cannot wait on a person. The prototype argues for a simpler shape: a
request is its own IAM record, holding who asked, which role, why, its state,
and who answered, when and why. It needs no engine change, and giving the role
reuses iam.v1.ops.assign_role, so the grant carries the same audit tail as any
other. What it still lacks, as the journey records, is a notice to either
person and a deadline after which an unanswered request closes.
Accepted on 2026-10-04. The user asked for the request to be held in a table that any approval in the system can use, an operations authorisation queue among them, and for notifications to be designed for any activity. Both are written up: Approval requests and Notification requirements.
2.4. What is real and what is not
The permission catalogue, its descriptions and the eight human roles with their bundles are exported from the deployment's seed data, and the five pictures are Acme's seeded staff photos, cropped small. The people, their grants and the reasons are mock.
The server does not yet support everything drawn:
- A reason on giving and taking away.
iam.v1.ops.assign_roleandiam.v1.ops.revoke_rolecarry an account and a role only. The grant row has the columns; the requests need the reason and the commentary. - A guard on taking away one's own administration, and on deleting a held role. Neither exists on the server.
2.5. Where the code lives
doc/prototypes/access/access/index.html: one file, plain HTML, CSS and JavaScript,
no framework and no build step. The site build copies the directory through
ores-deploy-web-app, beside the other prototypes.
3. See also
- Prototypes — the index of every prototype, and where to open each one.
- Home screen prototype — the shell these screens sit in.