implement recommended recipient api for unified sharing

[icewind1991]

Summary

Add api for suggesting recipients for a share

TODO

• Actually testing the implementation
• Adding tests

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)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[provokateurin]

My idea was to incorporate this into the existing search endpoint and have it trigger when the query is empty. I think this would simplify it a bit on the frontend/client side.

While the implementation with greater than instead of offset is much better than the Collaboration API provides, I don't think it is necessary, because in the current use case only a limited set of results is desired anyway (I think 3) and there is no pagination.

So I think making it part of the existing search endpoint would work and the query could just be limited to 3 all the time (without any sort of pagination).

If we want to have it work in a different way at some point, we can just do that later.

[provokateurin]

You can set these descriptions as keys for the array. PHPUnit will also log them on failure, which makes it easier to figure out which case is failing.

[icewind1991]

My idea was to incorporate this into the existing search endpoint and have it trigger when the query is empty. I think this would simplify it a bit on the frontend/client side.

Sounds good, will adjust it

While the implementation with greater than instead of offset is much better than the Collaboration API provides, I don't think it is necessary, because in the current use case only a limited set of results is desired anyway (I think 3) and there is no pagination.

Couldn't get the after logic working anyway, so had to switch to the basic `offset

[icewind1991]

/backport to stable35

[provokateurin]

@icewind1991 did you forget to push?

[skjnldsv]

sharing_share_recipients only has a PK on id, no index on share_id or initiator_user_id. So this joins and groups over the whole table, and the NOT IN scans it again. The picker hits this on every open, which means two full scans each time on bigger instances. Can we add the indexes here?

[skjnldsv]

Couple of small things:

• coalesce uses #[Override] while the rest of that file uses #[\Override]
• the new RuntimeException when there is no session user gives a 500, a 401 would say more. The route is NoAdminRequired so it should not happen anyway