Removing a teammate's viewer grant gives them edit access Issue open
Found by Paul on 2026-09-01, by asking what the point of the revoked-team notice was (issue #7). Measured on c4a3954, still true on 9b723a5.
Removing a teammate's viewer or commenter grant gives them edit access.
BEFORE revoke: role="viewer" mayWrite=false AFTER revoke: role="editor" mayWrite=true
roleFor (internal/sheets/grants.go) consults the explicit grant first and falls back to team standing only when no grant row exists. So an explicit grant is the only mechanism that holds a teammate BELOW their team standing of editor — and the control that deletes it is labelled Remove, styled rst-danger, and sits in the same column as the control that genuinely removes a guest's access.
It is on the fastest path through the screen. shareableRoles is least-able-first precisely so that somebody who types an address, presses Share and never opens the dropdown grants viewer rather than owner. That ruling is right and should stay. Its consequence here is that the quickest way to share with a teammate produces exactly the restricting grant whose removal escalates them.
Ruled by Paul, 2026-09-01: the behaviour stays and the notice is what changed. 9b723a5 makes the sentence tell the truth about the outcome. This issue exists so the underlying shape is recorded rather than rediscovered — a notice that describes an escalation politely is still an escalation.
A second honesty gap on the same screen, and they compound. grantsOn reads only the Grant table, while its doc comment says it "lists who can reach a sheet" and the heading above it reads Who has access. Every teammate can edit every sheet on the instance without appearing there. So after a revoke the person vanishes from the list and gains edit access in the same action, and the list offers no way to notice.
Options, if this is ever picked up. Naming them so the next session does not re-derive them:
- Name the control for what it does to that row — "Restore team access" where removing the grant would widen access, "Remove" where it would not.
- Refuse the revoke for a teammate whose grant restricts them, the way the last-owner orphan is refused.
- Make team standing a floor rather than a fallback: an explicit grant may only widen, never narrow. Removes the escalation by removing the capability, so it is the largest change and the one that deletes something that currently works.
- Fix the list independently: show who can reach the sheet, marking which access is a grant and which is team standing. Worth doing under any of the three above, and the only one that also fixes the heading.
Trigger for picking it up: somebody wants to hold a teammate below editor on a sheet and have it stay that way.