The edit entry appears only when the person may edit

What it is

Edit on a view surface is the door into the writable surface. That door should exist only when the current identity can actually write. Showing the same button to someone without edit permission, then failing with “forbidden,” teaches permission by failure. Hiding the entry, or replacing it with Request edit, is the surface that matches the grant. This is not whether the two chromes look different. It is whether the door is present. How roles are graded lives in sharing settings; here the grant has already landed on view, and the entry must be true with it.

Why it happens

Seen means tappable; tappable means expected success. A disabled or fail-after Edit starts two wrong paths: repeated taps, or hunting another door because the product looks broken (duplicate and edit, download and edit). Hiding the entry stops the expectation before it forms: people finish the job in view, and request or find the author when they need to write. For people who do have the grant, the entry must be obvious, or view becomes a trap—writers do not know they can write, and collaboration stalls in comments. If permission is revoked mid-session, a still-showing entry fails as “had it a moment ago,” which is worse than “never had it.” Request edit that looks like Edit again disguises no-permission as permission.

Studying it

One document, accounts that can write, view-only, and request. Compare: all three see Edit, view-only does not, view-only sees it disabled.

Independent variables: hidden versus disabled versus fail-after for no grant, whether mid-session revoke updates the entry. Dependent variables: view-only taps on Edit, belief that the product is broken, writers who cannot find the entry.

If the lab writes the grant on the task sheet, the entry test is skipped. Start from view, without “you cannot change this.” Revoke mid-session without a full reload. Do not fold “does edit look like view” into the same metric.

Where it stops holding

A public wiki that anyone may edit should show the entry to anonymous users; the model is open. When law requires an audit of “tried to edit,” use request instead of hide, but request must not look like immediate write. A bulk toolbar whose selection mixes granted and forbidden items should say which cannot enter, not one button that fails for part of the set. On mobile, Edit in overflow must remain discoverable for people who have the grant; narrowness is not a reason to hide the door the same way as no permission.

Applying it

• Do not render Edit without write permission. When an upgrade is possible, use Request edit or Contact author, with copy that is not the same as entering edit.
• With write permission, the entry is visible on the first view screen, not only inside More.
• After revoke, the entry vanishes in this session. If edit mode is already open, exit to view and say why.
• Verify: a view-only account opens the document; no control that enters edit is on the page. A writer on the same page can point to the entry. Revoke that writer without re-login; the entry disappears.

Related

• Within the group: H8.09.1 Edit and view modes need a readable visual split · H8.09.3 Unexpected exit should keep a draft, not drop the work · H8.09.4 One person’s edit mode must not hijack others’ viewing
• Adjacent: H8.08 Sharing Scope and Permission Settings · H8.01 CRUD Operations · H8.07 Collaborative Edit Conflicts
• Search terms: edit permission · gated affordance · view only