fix(sharing): do not notify remote if owner and sharee are local users

[kesselb]

• Resolves: [Bug]: Share not found error when creating a federated share from a share #57928

Summary

This one is a bit tricky and caused me some headaches 🤯

Steps to reproduce:

• Alice@A shares a folder with Bob@A
• Bob@A re-shares that folder with Jane@B
• An error toast is shown

The ShareNotFound exception is thrown in FederatedShareProvider.getRemoteId when there is no record in federated_shares. That seems like a valid state, since Alice and Bob are both on instance A.

The check in FederatedShareProvider.update only verifies that alice != bob and therefore calls FederatedShareProvider.sendPermissionUpdate. However, because Alice and Bob are on the same instance, there is no need to send a permission update to a remote server.

This change adjusts the condition accordingly, similar to what was done in oC a few years ago.

Given that this code path has barely been touched in recent years, it was surprising to see this error now. My assumption is that updating federated shares used to be a relatively uncommon operation, and since it usually worked despite that error, there were no reports.

Since #51250, we now call create followed by update when creating a share, which makes this case much more likely to occur and exposes the issue more frequently.

How to test:

Case 1:

• Alice@A shares a folder with Bob@A
• Bob@A re-shares that folder with Jane@B
• See the success toast

Case 2:

• Bob@A unshares the folder with Jane@B
• See the success toast

(Note: Unsharing works, but item is not removed from the share list in the view currently. That's unrelated to this pr.)

Case 3:

• Alice@A unshares the folder with Jane@B
• See the success toast

(Note: Unsharing works, but item is not removed from the share list in the view currently. That's unrelated to this pr.)

Tests:

I agree the tests are not great due to the heavy mocking around the query builder and related components. Still, I thought it was important to have at least some validation that the correct code path is executed.

The existing FederatedShareProviderTest does not write anything into the federated_shares table, so this code path is never called there.

Once the app is migrated to our usual QBMapper, the tests should become much cleaner and easier to maintain.

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[miaulalala]

Looks good

[miaulalala]

Looks good