feat(sharing): master switch for public share links, and a policy tab that reads in decision order

Cordy commented

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

Owner

Built test-first. Three commits: RED (field + tests, one failing), GREEN (four lines of enforcement), then the UI.

The switch

settings.ShareLinksDisabled turns off creation of new public share links instance-wide. shareCreate rejects with 400 policy: public share links are turned off on this server, checked before the password and expiry rules, so there is no combination of other settings that lets a link through.

Stored negative, deliberately. A ShareLinksEnabled bool would default to Go's zero value — false — and every existing instance would silently lose share links on upgrade, because its settings.json has no such key. ShareUploadsForbidden already solves this the same way. The UI inverts both, so the labels read the right way round without a config migration.

Three tests, each pinning a claim that can break independently:

Test	Claim
`TestShareLinksDisabledRejectsCreation`	the API refuses, not merely the dialog
`TestShareLinksEnabledWhenUnset`	the zero value leaves sharing on
`TestShareLinksDisabledLeavesExistingLinks`	disabling does not revoke

Only the first was red before the enforcement commit; the other two were written to fail loudly if the implementation broke behaviour it had no business touching. That was checked, not assumed — the RED run asserted the enforcement test failed on its want 400 assertion and that the other two already passed.

The policy tab

Rows now run capability → constraint → defaults → timings: whether links may exist at all, whether they must carry a password, whether they may take uploads, whether uploads are on by default, then the two expiry ceilings. Previously the two dropdowns came first and the switches after, which is schema order, not decision order.

Forbid upload links becomes Allow upload links — same stored field, inverted in the UI. Labels shortened now that the page title supplies the context (Default share expiry → Default expiry). Page description changed from "Instance-wide share link policy." to "Who may create share links, and the limits the server enforces on them."

Nine i18n keys upserted across four languages; two that lost their last caller (sdNoUpload, shareForbidUploads) were removed, and the splice asserted no references survive.

Not in this PR

Non-operator visibility — a regular user still discovers the policy by being rejected after filling in the dialog. That is #351, with the three candidate designs and the argument against each written up.

Verification

go build ./..., go vet, go test ./internal/api/... ./internal/settings/... all pass. node --check on the extracted script blocks passes. Row order asserted programmatically rather than eyeballed.

Built test-first. Three commits: RED (field + tests, one failing), GREEN (four lines of enforcement), then the UI. ## The switch `settings.ShareLinksDisabled` turns off creation of new public share links instance-wide. `shareCreate` rejects with `400 policy: public share links are turned off on this server`, checked **before** the password and expiry rules, so there is no combination of other settings that lets a link through. **Stored negative, deliberately.** A `ShareLinksEnabled bool` would default to Go's zero value — `false` — and every existing instance would silently lose share links on upgrade, because its `settings.json` has no such key. `ShareUploadsForbidden` already solves this the same way. The UI inverts both, so the labels read the right way round without a config migration. Three tests, each pinning a claim that can break independently: | Test | Claim | |---|---| | `TestShareLinksDisabledRejectsCreation` | the API refuses, not merely the dialog | | `TestShareLinksEnabledWhenUnset` | the zero value leaves sharing **on** | | `TestShareLinksDisabledLeavesExistingLinks` | disabling does not revoke | Only the first was red before the enforcement commit; the other two were written to fail loudly if the implementation broke behaviour it had no business touching. That was checked, not assumed — the RED run asserted the enforcement test failed on its `want 400` assertion and that the other two already passed. ## The policy tab Rows now run **capability → constraint → defaults → timings**: whether links may exist at all, whether they must carry a password, whether they may take uploads, whether uploads are on by default, then the two expiry ceilings. Previously the two dropdowns came first and the switches after, which is schema order, not decision order. `Forbid upload links` becomes `Allow upload links` — same stored field, inverted in the UI. Labels shortened now that the page title supplies the context (`Default share expiry` → `Default expiry`). Page description changed from "Instance-wide share link policy." to "Who may create share links, and the limits the server enforces on them." Nine i18n keys upserted across four languages; two that lost their last caller (`sdNoUpload`, `shareForbidUploads`) were removed, and the splice asserted no references survive. ## Not in this PR Non-operator visibility — a regular user still discovers the policy by being rejected after filling in the dialog. That is #351, with the three candidate designs and the argument against each written up. ## Verification `go build ./...`, `go vet`, `go test ./internal/api/... ./internal/settings/...` all pass. `node --check` on the extracted script blocks passes. Row order asserted programmatically rather than eyeballed.

Cordy added 10 commits

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

scout: sharing policy surface 33ea4b3a00

scout: shares policy enforcement + test harness 092ba509c3

test: public share links master switch (RED) dbd3113919

one-shot: RED — field only, no enforcement b59d6ec0a2

test(shares): master switch for public share links (RED) 0a6cb53613

Adds settings.ShareLinksDisabled and three tests. Only the enforcement
test fails; the other two already hold and are here to pin behaviour
the implementation must not break:

  - the zero value must leave sharing ON, since an upgrading instance
    has no such key in settings.json;
  - disabling must not revoke links that already exist.

Field is stored negative for exactly that first reason.

one-shot: GREEN — enforce the switch 47588ed6f3

feat(shares): enforce the public share links master switch (GREEN) d38f30aac7

Four lines in the existing policy block. Checked first, so a disabled
instance refuses before the password and expiry rules have anything to
say -- there is no combination of other settings that lets a link
through.

Create-time only: the two tests pinning the zero value and the
no-revoke promise still pass untouched.

temp: sharing page i18n source (upsert; key|en|de|fr|it) 6b8b63579a

one-shot: sharing page UI 14805f0824

feat(admin): rebuild the Sharing policy tab

ci / test-and-build (pull_request) Successful in 41s

Details

fa338c915f

Rows now run capability, constraint, defaults, timings: whether links may
exist at all, whether they must carry a password, whether they may take
uploads, whether uploads are on by default, then the two expiry ceilings.
Reading the page top to bottom now follows the decision, not the schema.

Public share links is the new master switch. Allow upload links replaces
Forbid upload links: both settings stay stored negative, and the UI
inverts them, so no config migration is needed for a label that reads
the right way round.