Federated share with known user leads to wrong message

[dj4oC]

As a user, I want to share a file with an external, but federated user.
I already shared files with this user so the user is known already by the system.
Then I enter the Federated ID, I get the message: "Kein Benutzer oder Gruppe grunfunden für ID".
But the correct user is listes below since I have shared with him already.
Please correct message to: User had been added to already. Please choose from list below.

ownCloud 10.14.3

@gvlidiya

[DeepDiver1975]

unrelated to federated sharing - happens with "normal" sharing as well

[DeepDiver1975]

API provides necessary data to add the required logic to the frontend.

Effort: 3md

[DeepDiver1975]

draft fix: #41264

[dj4oC]

Triage note (2026-06): still reproducible on core master. The share dialog filters an already-shared sharee out of the autocomplete suggestions, and when that sharee is the only match the code falls through to the generic "No users or groups found for {search}" message in core/js/sharedialogview.js, even though the already-shared user is shown in the list below. As noted earlier this is not federation-specific and also occurs with regular sharing. The draft fix in #41264 (add an alreadyShared flag and show "User/group already shared with.") was closed unmerged in Nov 2024. Leaving this open as a known low-priority UX bug; the prior draft remains a valid starting point for anyone picking it up.

[DeepDiver1975]

🤖 Automated issue triage by Claude Code review agent.

Confirmed bug with a located root cause (consistent with @DeepDiver1975's earlier finding that this is not federation-specific, and @dj4oC's 2026-06 triage note).

Root cause — core/js/sharedialogview.js:

1. During autocomplete, sharees that are already shared with are removed from the suggestion list: core/js/sharedialogview.js:243-272 ("Now filter out all sharees that are already shared with" — loops over users/groups/remotes and splices out any entry whose value.shareWith matches an existing share.share_with).
2. When the only match for the typed search is that already-shared sharee, the resulting suggestions array is empty, so execution falls into the empty-suggestions branch at core/js/sharedialogview.js:328-329 and displays the generic t('core', 'No users or groups found for {search}') (or the No users found for {search} variant at line 331 when group sharing is disabled).

So the user sees "No users or groups found for …" (German: "Kein Benutzer oder Gruppe gefunden für ID") even though the already-shared user is visibly listed below in the existing-shares list. The message is misleading: the user was found, they are simply already shared with.

Why it is not federation-specific: the same filter+fallthrough applies to SHARE_TYPE_USER and SHARE_TYPE_GROUP (lines 247-262), so a regular already-shared user/group triggers the identical message — matching the screenshot in the earlier comment.

Prior art: the draft fix #41264 (add an alreadyShared flag and surface "User/group already shared with.") was closed unmerged in Nov 2024 but remains a valid starting point. The autocomplete backend already returns the needed data, so the fix is frontend-only: when the typed search matches an existing share that was filtered out, show an "already shared with" message instead of the generic "not found" string.

Severity remains low (UX-only, no data/functional impact). Leaving open as a known low-priority UX bug. Note: this repo is excluded from automated fix PRs, so this is triage/analysis only.

[dj4oC]

Implementation prompt

Problem: In the share dialog's sharee autocomplete, when the only match for a typed search is a sharee already shared with, that entry is filtered out of suggestions and the UI falls back to the generic "No users or groups found for {search}" message instead of telling the user the sharee was found but is already shared with.

Acceptance criteria:

• When autocomplete filters out an already-shared user/group/remote because it matches the typed search, the dialog shows an "already shared with" message instead of the generic "No users or groups found for {search}".
• Behavior applies uniformly to SHARE_TYPE_USER, SHARE_TYPE_GROUP, and SHARE_TYPE_REMOTE (confirmed not federation-specific — the same filter/fallthrough code handles all three).
• Existing message for a genuinely-not-found search is unchanged.
• No regression to the batch-add flow (_getUsersForBatchAction), which has its own separate filtering.

Files:

• core/js/sharedialogview.js — in autocompleteHandler, the "Now filter out all sharees that are already shared with" loop (splices matching entries out of users/groups/remotes) currently discards why an entry was removed. Track whether suggestions.length < 1 is a direct result of that filtering (vs. a genuine zero-match search), and in that case show a distinct message (e.g. "User/group already shared with.") instead of t('core', 'No users or groups found for {search}', ...) at the bottom of the function.
• A closed draft, PR fix: show different message when resource was already shared with the… #41264, added an alreadyShared flag for this — valid prior art, not required to reuse verbatim.

Constraints:

• Test coverage ≥ 85% on touched code (e2e preferred — run the tool, do not trust claimed %)
• WCAG 2.2: the new message must be surfaced through the same accessible mechanism as the existing _displayError tooltip (aria-live parity)
• Commit signing: GPG signature + DCO Signed-off-by
• Rebase onto base branch before push
• No root-directory edits

🤖 Automated by Claude Code

---

Generated by Claude Code