fix: unified search provider id

[SebastianKrupinski]

Issue

Unified Search not searching dav properly

Unified search backend use the provider id to match providers but the front end was using the app id.

This works fine for most search providers as the app id and provider id are the same in most cases (e.g files app; app id is 'files', search provider id is 'files') but in other cases like dav this breaks (e.g. dav app; app id is 'dav' but search provider is 'contacts or events')

Also using the app id is not a good choice as one app can have multiple providers registered (e.g. dav has Contacts, Events and Tasks search)

Resolution

Modify front end to use provider id instead of app id

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)

[SebastianKrupinski]

/compile amend

[nfebe]

I would look into this asap

[SebastianKrupinski]

@nfebe your commit broker this again.

You can not just make up your own provider id, the id is being sent as 'dav-contacts' which is not valid.

What issue are you trying to solve maybe I can help you find a proper solution?

[nfebe]

You can not just make up your own provider id, the id is being sent as 'dav-contacts' which is not valid.

Sorry, I converted it to WIP, it's not supposed to use that there a corresponding frontend change which I am adjusting.

[nfebe]

Also using the app id is not a good choice as one app can have multiple providers registered (e.g. dav has Contacts, Events and Tasks search)

Sure, I added a searchFrom property to in in-folder search plugin we could use this in the backend, my attempted backend changes where reverted as it would need much more work.

I have added a commit that restores full function with apps like dav while still having in-folder search working as expected.

---

TODO:

• Ensure "load more results" removes other filters

[SebastianKrupinski]

/compile amend

[provokateurin]

Reminds me of #47523 😞
I really dislike when this kind of mess comes to haunt us back way later.
It works almost fine because in most cases it works, but we don't test good enough for "edge cases" (which aren't really edge cases tbh because it's just standard behavior).

[nfebe]

/backport to stable31

[nfebe]

/backport to stable30