fix: show federated users in the share dialog when local users also match

[oc-tmueller]

Description

The share dialog only appended federated sharees when the search returned no local users and no local groups:

var suggestions = users.concat(groups);
if (suggestions.length < 1 && !isBatch) {
	suggestions = suggestions.concat(remotes);
}

A single local match - including a partial one - therefore hid every federated result, exact federated cloud id matches included. If a federated user's name shares a stem with any local account (e.g. federated Kamp,Andrea on one instance, local Bouwkamp and Haverkamp on the other), the federated user becomes unreachable from the share dialog unless the full cloud id is typed.

Root cause

That frontend filter was introduced in #38389 to hide a suggestion the server generates: ShareesController::getRemote() offers the raw search term as a federated cloud id whenever it merely contains an @, so typing the email address of an existing local account produced a bogus federated suggestion next to the real one.

The backend already tried to guard against this, but only dropped the guess when the address' domain part was listed in trusted_domains. For a typical deployment (mail @company.com, instance cloud.company.com) that never matches, which is why the far broader frontend filter was reached for.

Fix

Suppress the speculative entry at its source: getRemote() now skips it whenever the search term already matched a local user or group exactly - the local account wins. With the noise gone, the share dialog can append federated results unconditionally again.

Note this only affects the generated guess (the sole remote entry that carries no value.server); federated contacts found in the address book and remotes returned by a sharing.remoteShareesSearch plugin are unaffected.

isInstanceDomain() has no remaining callers and is removed.

Behaviour change

ShareesTest case #15 is inverted deliberately: an exact local user now wins even when the email domain is not a trusted domain.

Tests

• apps/files_sharing/tests/API/ShareesTest.php: case use post to delete files, get has a limit and fails with many files #15 updated; new cases for an exact local group suppressing the guess, and for an address-book federated contact surviving alongside an exact local user.
• core/js/tests/specs/sharedialogviewSpec.js: two specs covering a federated sharee alongside partially matching local users, and an exact federated match alongside a matching local group. Both fail without the change in core/js/sharedialogview.js.

Verified locally: ShareesTest 333 tests / 875 assertions green; share dialog karma spec 40/41 (1 pre-existing skip) green.

Related

• Hide federated user suggestions when sharing if system users are found #38389 (introduced the frontend filter)
• https://github.com/owncloud/enterprise/issues/4392

🤖 Generated with Claude Code

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.