#589 - The "Can upload" role was never built — share dialog offers only view and edit (#529 2/3 follow-up) - Cordy/Cairn

Cordy commented

2026-09-18 00:48:27 +00:00

Owner

Found in the v0.6.213 live pass.

What happens

Opening the share dialog on a folder (/home/moverini), the role select beside the recipient picker contains exactly two options:

<select>
  <option value="read"  selected>Can view</option>
  <option value="write">Can edit</option>
</select>

There is no third option.

What #571 specified

Roles as three labels over primitives that already exist — Can view → read, Can edit → write, Can upload → AllowUpload, the last shown for folders only.

So Can upload is missing entirely, not merely mis-gated. The folder-only condition cannot be the explanation: this was tested on a folder, and the dialog's own public-link section correctly shows Allow uploads (file drop) for the same folder and correctly hides it for a file — so the folder/file distinction is already wired elsewhere in the same dialog.

Notes for the fix

AllowUpload already exists as a primitive on the public-link side; this is a third label over it on the grant side, not new backend capability. Worth checking first whether the grant model and the POST accept it at all, or whether the backend also stopped at two roles — the API slice (#575) predates the UI, so it may or may not carry it.
Role labels are i18n ×4.
The select needs the same folder/file condition the Allow uploads (file drop) checkbox already uses; reuse that predicate rather than writing a second one, so the two cannot drift.
If a grant carrying AllowUpload can be created, the recipient's toolbar must then actually offer Upload file — which today it offers regardless of role. That interaction is #588, and the two should be verified together rather than separately.

Reproduce

Share a folder with any account.
Look at the role select.

Found in the v0.6.213 live pass. ## What happens Opening the share dialog on a **folder** (`/home/moverini`), the role select beside the recipient picker contains exactly two options: ``` <select> <option value="read" selected>Can view</option> <option value="write">Can edit</option> </select> ``` There is no third option. ## What #571 specified > **Roles** as three labels over primitives that already exist — Can view → `read`, Can edit → `write`, Can upload → `AllowUpload`, the last shown for folders only. So `Can upload` is missing entirely, not merely mis-gated. The folder-only condition cannot be the explanation: this was tested on a folder, and the dialog's own public-link section correctly shows `Allow uploads (file drop)` for the same folder and correctly hides it for a file — so the folder/file distinction is already wired elsewhere in the same dialog. ## Notes for the fix - `AllowUpload` already exists as a primitive on the public-link side; this is a third label over it on the grant side, not new backend capability. Worth checking first whether the grant model and the `POST` accept it at all, or whether the backend also stopped at two roles — the API slice (#575) predates the UI, so it may or may not carry it. - Role labels are i18n ×4. - The select needs the same folder/file condition the `Allow uploads (file drop)` checkbox already uses; reuse that predicate rather than writing a second one, so the two cannot drift. - If a grant carrying `AllowUpload` can be created, the recipient's toolbar must then actually offer `Upload file` — which today it offers regardless of role. That interaction is #588, and the two should be verified together rather than separately. ## Reproduce 1. Share **a folder** with any account. 2. Look at the role select.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-09-18 00:48:28 +00:00

Cordy referenced this issue

2026-09-18 00:48:59 +00:00

A read-only grant offers the full write menu under /shared (#529 2/3 follow-up) #588

Cordy referenced this issue

2026-09-18 00:49:15 +00:00

Share panel: people and groups first, links split internal/public (#529, 2/3) #571

Cordy referenced this issue

2026-09-18 00:50:49 +00:00

Docs run: the handbook still says a share is a link (#529 2/3, shipped v0.6.212) #585

Cordy referenced this issue

2026-09-18 01:20:54 +00:00

docs(#585): the handbook stops saying a share is a link #591

Cordy commented

2026-09-18 01:40:25 +00:00

Author

Owner

Closing as superseded — the two-role select is the approved design, not a gap.

This issue was cut against #571's issue body ("Roles as three labels... Can upload → AllowUpload, the last shown for folders only"), which predates the mockup review. The rev-2 implementation mockup (share-panel-571-mockup-rev2.html, block 0, under "Settled in rev 1, not redrawn here") records the settlement:

roles are Can view / Can edit, with upload a public-link checkbox rather than a per-person role (5).

The implementation matches that settlement exactly, on both sides:

internal/share/share.go: "Role is "read" or "write", reusing spacestore's vocabulary" — and grantCreate hard-refuses anything else (role must be "read" or "write").
The dialog offers Can view / Can edit, and the folder case keeps upload where the settlement put it: the Allow uploads (file drop) checkbox on the public-link section, which correctly appears for folders and not for files.

So the code, the backend validation, and the approved mockup all agree with each other; only the issue body from before the review disagreed. Writing the third role now would be implementing superseded intent — the same mistake #124 exists to prevent in docs.

The docs run (#585 / #591) documents two roles as the design, with the mockup's reasoning: "drop files here" workflows are upload links or spaces, not per-person roles.

If a per-person upload role is ever actually wanted, that is a new design decision — reopen against a fresh mockup round, not against this thread.

**Closing as superseded — the two-role select is the approved design, not a gap.** This issue was cut against #571's issue body ("Roles as three labels... Can upload → `AllowUpload`, the last shown for folders only"), which predates the mockup review. The rev-2 implementation mockup (`share-panel-571-mockup-rev2.html`, block 0, under **"Settled in rev 1, not redrawn here"**) records the settlement: > roles are *Can view* / *Can edit*, with upload a public-link checkbox rather than a per-person role (5). The implementation matches that settlement exactly, on both sides: - `internal/share/share.go`: *"Role is "read" or "write", reusing spacestore's vocabulary"* — and `grantCreate` hard-refuses anything else (`role must be "read" or "write"`). - The dialog offers `Can view` / `Can edit`, and the folder case keeps upload where the settlement put it: the `Allow uploads (file drop)` checkbox on the public-link section, which correctly appears for folders and not for files. So the code, the backend validation, and the approved mockup all agree with each other; only the issue body from before the review disagreed. Writing the third role now would be implementing superseded intent — the same mistake #124 exists to prevent in docs. The docs run (#585 / #591) documents two roles as the design, with the mockup's reasoning: "drop files here" workflows are upload links or spaces, not per-person roles. If a per-person upload role is ever actually wanted, that is a new design decision — reopen against a fresh mockup round, not against this thread.

Cordy closed this issue

2026-09-18 01:40:31 +00:00

Cordy referenced this issue

2026-09-18 01:46:24 +00:00

docs: v0.6.214 changelog entry #594

Cordy referenced this issue

2026-09-18 02:01:58 +00:00

Docs run: the handbook still says a share is a link (#529 2/3, shipped v0.6.212) #585

Cordy referenced this issue

2026-09-18 02:02:14 +00:00

Share panel: people and groups first, links split internal/public (#529, 2/3) #571