Non-operator UI for the public share links master switch #351

New issue

Closed

opened 2026-08-28 01:18:20 +00:00 by Cordy · 0 comments

Cordy commented

2026-08-28 01:18:20 +00:00

Owner

What exists after #352

settings.ShareLinksDisabled is a real, enforced master switch. shareCreate rejects any new link with 400 policy: public share links are turned off on this server, checked before the password and expiry rules so no combination of other settings gets a link through. Existing links keep working; revocation stays on Sharing → Active links.

The gap

Enforcement is correct but invisible to the people it affects. A regular user today:

selects a file,
opens the share dialog,
fills in a password and an expiry,
presses create,
gets a rejection.

Every step after the first is wasted work, and the error arrives at the point of most investment. The switch is an instance-wide policy, so it should be legible before the dialog, not enforced after it.

Scope

Decide and build how a non-operator learns that public share links are off.

The data is already there: shareLinksDisabled rides in the same serverSettings object the share dialog already reads for shareRequirePassword, shareUploadsForbidden, shareMaxExpiry and shareDefaultExpiry (web/static/index.html, around the share-dialog setup). No new endpoint is needed.

The design question is which of these it should be, and the answer is not obvious:

Hide the Share action entirely. Cleanest surface, but a control that vanishes is indistinguishable from a bug or a missing permission — the user cannot tell whether sharing is off, or off for them.
Keep it visible and disabled, with a reason on hover or in the dialog. Slower to reach, but it answers the question the user actually has. Note the house rule against disabled controls that give no explanation — a disabled Share button with no tooltip is the worst of both.
Let the dialog open and state the policy in place of the form. Most explanatory, most clicks. Matches the graceful not-enabled notice already used for peering (#131), so there is precedent and a copy pattern to reuse.

Whichever wins should also cover WebDAV and API callers, who get the 400 and nothing else — at minimum the error string should read as policy rather than failure, which it currently does.

Definition of done

A user on an instance with sharing off understands that before they invest any effort, and the reason is attributable to instance policy rather than to their own account.
The admin copy stays true: turning the switch off still does not revoke existing links, and a user holding one is unaffected.
Whatever pattern is chosen is the same one a future instance-wide switch would use, rather than a one-off for this setting.

#352 — the switch, its enforcement, and the admin row
#131 — the peering not-enabled notice, as the nearest existing precedent

## What exists after #352 `settings.ShareLinksDisabled` is a real, enforced master switch. `shareCreate` rejects any new link with `400 policy: public share links are turned off on this server`, checked before the password and expiry rules so no combination of other settings gets a link through. Existing links keep working; revocation stays on **Sharing → Active links**. ## The gap Enforcement is correct but invisible to the people it affects. A regular user today: 1. selects a file, 2. opens the share dialog, 3. fills in a password and an expiry, 4. presses create, 5. gets a rejection. Every step after the first is wasted work, and the error arrives at the point of most investment. The switch is an instance-wide policy, so it should be legible *before* the dialog, not enforced after it. ## Scope Decide and build how a non-operator learns that public share links are off. The data is already there: `shareLinksDisabled` rides in the same `serverSettings` object the share dialog already reads for `shareRequirePassword`, `shareUploadsForbidden`, `shareMaxExpiry` and `shareDefaultExpiry` (`web/static/index.html`, around the share-dialog setup). No new endpoint is needed. The design question is which of these it should be, and the answer is not obvious: - **Hide the Share action entirely.** Cleanest surface, but a control that vanishes is indistinguishable from a bug or a missing permission — the user cannot tell whether sharing is off, or off *for them*. - **Keep it visible and disabled, with a reason on hover or in the dialog.** Slower to reach, but it answers the question the user actually has. Note the house rule against disabled controls that give no explanation — a disabled Share button with no tooltip is the worst of both. - **Let the dialog open and state the policy in place of the form.** Most explanatory, most clicks. Matches the graceful not-enabled notice already used for peering (#131), so there is precedent and a copy pattern to reuse. Whichever wins should also cover WebDAV and API callers, who get the 400 and nothing else — at minimum the error string should read as policy rather than failure, which it currently does. ## Definition of done - A user on an instance with sharing off understands that before they invest any effort, and the reason is attributable to instance policy rather than to their own account. - The admin copy stays true: turning the switch off still does not revoke existing links, and a user holding one is unaffected. - Whatever pattern is chosen is the same one a future instance-wide switch would use, rather than a one-off for this setting. ## Related - #352 — the switch, its enforcement, and the admin row - #131 — the peering not-enabled notice, as the nearest existing precedent