#681: federated share from the panel - direct user@server candidate #712

Merged

Cordy merged 9 commits from feat-681 into main 2026-09-24 03:02:23 +00:00

Conversation 0 Commits 9 Files changed 3 +82

Cordy commented 2026-09-24 02:59:26 +00:00

Owner

Copy link

Closes #681

Root cause. The panel's federated Add path (built in #603) exists and works — sharePick.kind === "federated" posts to /api/v1/ocm/shares, which validates the allow-list, discovers and sends (interop green). But its only candidate source was shareFedMatches(shareFedContacts, q) — the invited contacts list — and typing deliberately resets sharePick (the #571 pick-to-enable guard). With contacts [], a policy-any server could never produce a candidate, so Add stayed disabled. /api/v1/recipients being local-only is by design (user-enumeration guard), not the bug.

Fix (UI only, no backend change).

• New pure helper shareFedDirect(q, servers, existing) in its own pure:fed-direct lift-block: parses user@host, matches the host case-insensitively against allow-listed policy-"any" servers, returns the canonical fqdn, and dedupes against contacts already offered.
• The share dialog loads shareFedServers (policy-any fqdns from GET /api/v1/ocm/shares) alongside the contacts fetch.
• shareSearchRecipients appends the direct candidate to the federated list — the existing render, pick, Add branch, and boundary note are reused untouched.

Decisions. Direct addressing is offered only for policy-any servers ("invited contacts only" keeps the contacts flow, matching the admin copy); typing user@<non-allow-listed host> still offers nothing rather than a row that would 403 on Add.

Tests. web/test/qa681.test.js: unit pins on the lifted helper (valid/unknown-host/malformed/dedupe/case-insensitivity + canonical fqdn) and wiring pins. This unblocks the rest of QA §5 (accept/decline inbound, federated revoke, Shares-view rows).

Closes #681 **Root cause.** The panel's federated Add path (built in #603) exists and works — `sharePick.kind === "federated"` posts to `/api/v1/ocm/shares`, which validates the allow-list, discovers and sends (interop green). But its only candidate source was `shareFedMatches(shareFedContacts, q)` — the *invited contacts* list — and typing deliberately resets `sharePick` (the #571 pick-to-enable guard). With contacts `[]`, a policy-`any` server could never produce a candidate, so Add stayed disabled. `/api/v1/recipients` being local-only is by design (user-enumeration guard), not the bug. **Fix (UI only, no backend change).** - New pure helper `shareFedDirect(q, servers, existing)` in its own `pure:fed-direct` lift-block: parses `user@host`, matches the host case-insensitively against allow-listed **policy-"any"** servers, returns the canonical fqdn, and dedupes against contacts already offered. - The share dialog loads `shareFedServers` (policy-`any` fqdns from `GET /api/v1/ocm/shares`) alongside the contacts fetch. - `shareSearchRecipients` appends the direct candidate to the federated list — the existing render, pick, Add branch, and boundary note are reused untouched. **Decisions.** Direct addressing is offered only for policy-`any` servers ("invited contacts only" keeps the contacts flow, matching the admin copy); typing `user@<non-allow-listed host>` still offers nothing rather than a row that would 403 on Add. **Tests.** `web/test/qa681.test.js`: unit pins on the lifted helper (valid/unknown-host/malformed/dedupe/case-insensitivity + canonical fqdn) and wiring pins. This unblocks the rest of QA §5 (accept/decline inbound, federated revoke, Shares-view rows).

Cordy added 9 commits 2026-09-24 02:59:27 +00:00

scout(#681): share panel picker, Add gating, ocm/shares UI callers 824618585a

scout(#681b): shareFedMatches, contacts loader, fedhint toggle, ocm-interop test shape d7901edc24

test(#681): RED - direct federated candidate for policy-any allow-listed servers 0add3f3a42

splice(#681): direct federated candidate wiring in the share panel 320b8b06f4

one-shot(#681): RED gate, splice, web checks, self-cleaning commit 543d555087

fix(#681): federated share from the panel - direct user@server candidate ... 372937dc5d

A policy-any allow-listed server no longer needs an invited contact: typing a full federated address offers a direct candidate (canonical fqdn, contact-deduped) that rides the existing pick -> Add -> POST /api/v1/ocm/shares path. Helper ships as a pure lift-block with unit pins (qa681.test.js).

chg(#681): changelog entry for v0.6.262 e84bfd31ca

one-shot: apply v0.6.262 changelog entry, self-remove 3573aced1d

docs: changelog for v0.6.262 (#681 federated share from the panel) 77e3645e22

Cordy merged commit 47af96314e into main 2026-09-24 03:02:23 +00:00

Cordy referenced this pull request from a commit 2026-09-24 03:02:25 +00:00

Merge pull request '#681: federated share from the panel - direct user@server candidate' (#712) from feat-681 into main

Cordy deleted branch feat-681 2026-09-24 03:02:25 +00:00

Cordy referenced this pull request 2026-09-24 03:11:37 +00:00

QA re-verification run: confirm the fixes for the #656 findings (post-fix pass for Opus) #697

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#712

No description provided.