Case 02
Same person, three separate gates
Problem
On a client row, edit, note, session, voice recording, and sharing all show at once. Each of these opens through a different gate. If organization policy says “can see clients”, that does not mean they can edit that client. An open sharing panel also does not mean the other party has access. If the screen looks at a single “authorized” flag, it opens a note for someone without permission or hides sharing from someone who has it.
Context
CoBu has two layers. One is organization-wide: create client, delete, accounting for a lower rank or the same rank. The other is the client row itself: edit, see notes, add notes, open a session, record audio, attach a task. Sharing is a third thing. Opening the panel is one permission; granting access to someone is another record. And when a 403 arrives, the policy may be stale. If the organization wants MFA, this is not a “you don’t have permission” screen. The user goes to verification.
What I owned
[I wired the row actions to these three gates.]
Interface decisions
A button looks at that action’s own gate. See notes and add notes are separate. Seeing a session and creating a session are separate. Sharing shows if sharing is on for the organization and this row has share permission. If there is no permission, the button does not sit disabled and untappable. It takes no space. If the server still returns 403, raw error text is not printed. If it is policy-related, policy is refreshed quietly and the sentence becomes “you don’t have permission for this action”. If an MFA code arrives, that sentence is not used. The user goes to the MFA screen. When the organization changes, the previous client’s screen does not stay open. Protected text in memory belongs to that scope. Until the new organization’s list arrives, no action is allowed on the old row.
What I chose not to do
I did not pin every action to a role. Owner, admin, and staff are not the same on every client. When the row has permission I also did not ignore the org-wide policy. If sharing is off, row permission does not open the panel.
Quality
Two clients in the same list show different buttons. One adds notes, the other only views. In an organization with sharing off, the panel never appears. After a 403 the button disappears with the refreshed policy. In an organization that needs MFA, the permission sentence does not appear. [I verified these four states on this screen.]
Result
The screen hides an action the server would reject. If it still rejects, it does not show the server dump; it says what changed.
Next
[Lock save inside an open form when permission drops. Say which gate closed in one line.]