Federated share from the panel impossible: typing name@allowed-server offers no candidate and "Add" stays disabled #681

New issue

Closed

opened 2026-09-23 03:27:54 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-23 03:27:54 +00:00

Owner

Found by the #656 QA pass (v0.6.247, files → files-bao).

Matrix row: §5 OCM — "Federated share (policy any) | Share to name@peer from the panel | Recipient sees the pending share on their instance".

Preconditions (verified):

files settings.ocmEnabled = true.
files /api/v1/admin/ocm/servers lists files-bao.c0rdyceps.ch with policy any, Cairn, API 1.1.0.
files-bao lists files.c0rdyceps.ch as REACHABLE with "Any user on this server".
The ocm-interop workflow at v0.6.247 is green (wire level).

Steps

files, as nikola-test: _qa/qa-note.md → pane → Shares. The helper text reads "Also works across instances: type a federated address like name@files.other-org.ch."
Type sharer1@files-bao.c0rdyceps.ch with real keystrokes.
The UI calls GET /api/v1/recipients?q=sharer1@files-bao.c0rdyceps.ch → {"recipients":[]}. No picklist row appears, and Add stays disabled.
Pressing Enter does not add either. Instead it creates a public link (#680).

Expected: a federated candidate row ("sharer1 on files-bao.c0rdyceps.ch", say) is offered for any address whose host is on the allow-list, or Add enables for a syntactically valid user@allowed-host. The share is then sent over OCM.
Seen: there is no path from the panel to a federated share. /api/v1/ocm/contacts is [], so the "invited contacts only" path isn't what gates it. The server policy is already any.

That blocks the rest of §5 in this pass: accept/decline inbound, federated revoke, and the Shares-view federated rows are not tested.

Screenshot: 680-enter-creates-public-link.jpg shows the same panel state (empty people field after the Enter; Add disabled).

Found by the #656 QA pass (v0.6.247, files → files-bao). **Matrix row:** §5 OCM — "Federated share (policy any) | Share to name@peer from the panel | Recipient sees the pending share on their instance". **Preconditions (verified):** - files `settings.ocmEnabled = true`. - files `/api/v1/admin/ocm/servers` lists `files-bao.c0rdyceps.ch` with policy `any`, Cairn, API 1.1.0. - files-bao lists `files.c0rdyceps.ch` as REACHABLE with "Any user on this server". - The `ocm-interop` workflow at v0.6.247 is green (wire level). **Steps** 1. files, as nikola-test: `_qa/qa-note.md` → pane → Shares. The helper text reads "Also works across instances: type a federated address like name@files.other-org.ch." 2. Type `sharer1@files-bao.c0rdyceps.ch` with real keystrokes. 3. The UI calls `GET /api/v1/recipients?q=sharer1@files-bao.c0rdyceps.ch` → `{"recipients":[]}`. No picklist row appears, and **Add stays `disabled`**. 4. Pressing Enter does not add either. Instead it creates a public link (#680). **Expected:** a federated candidate row ("sharer1 on files-bao.c0rdyceps.ch", say) is offered for any address whose host is on the allow-list, or Add enables for a syntactically valid `user@allowed-host`. The share is then sent over OCM. **Seen:** there is no path from the panel to a federated share. `/api/v1/ocm/contacts` is `[]`, so the "invited contacts only" path isn't what gates it. The server policy is already `any`. That blocks the rest of §5 in this pass: accept/decline inbound, federated revoke, and the Shares-view federated rows are **not tested**. **Screenshot:** `680-enter-creates-public-link.jpg` shows the same panel state (empty people field after the Enter; Add disabled).