feat: reduce search providers per config value "unified_search_providers_allowed"

[printminion-co]

Summary

This feature should help to restrict not desired search providers by allowing only desired search providers.

Before

One can see the /ocs/v2.php/search/providers deliver various search providers (you may see other providers on your nextcloud instance depending on installed/disabled apps).

After feature activation

One can see we allowed only the files and settings search providers (since we do not want to allow any other search providers).

CLI Example: restrict search providers to files and settings

./occ config:app:set --value '["files","settings"]' --type array core unified_search.providers_allowed

• Resolves: #

TODO

• Disable search result on "disabled" providers e.g. /ocs/v2.php/search/providers/settings/search?term=f&from=%2Fapps%2Ffiles%2Ffiles

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)

[artonge]

Is the endpoint also not responding when searching in disabled providers?

[susnux]

I am not sure, as far as I know we do not have documentation about available search providers. So this config would be blind-guessing.
Maybe it is safer to make it an app config first until we have a occ command to list search providers?

[sorbaugh]

would be blind-guessing. Maybe it is safer to make it an app config first until we have a occ command to list search providers?

@printminion-co would this be ok for you?

[printminion-co]

I am not sure, as far as I know we do not have documentation about available search providers. So this config would be blind-guessing.

I've added more description and screenshots to better describe the feature.
There is no blind-guessing since we allow and not disable the search providers.

Maybe it is safer to make it an app config first until we have a occ command to list search providers?

• We know which providers we want keep enabled.
• We do not need a listing.
• Allowing not existing provider (e.g. foo) will not break the code

cc// @artonge @susnux @sorbaugh

[susnux]

We know which providers we want keep enabled.
We do not need a listing.

For you this might be true, but my fear is that this will confuse other administrators of Nextcloud systems, because of the missing listing / documentation.

There is no blind-guessing since we allow and not disable the search providers.

Well if you know that API endpoint to retrive the available providers yes. What I meant is:
There is no list of available providers in the documentation and no OCC command to query it,
so this would be a feature mostly hidden and undocumented.

That is why I asked if instead of system config also an app config would work? Instead of writing it to the config.php just have it as an core app setting, we could later built an OCC command around it (listing + dis-/enable).

From my side no blocker, but just wanted to bring this up as this might lead to confusion in the future.

[printminion-co]

Instead of writing it to the config.php just have it as an core app setting, we could later built an OCC command around it (listing + dis-/enable).

I will check this

[printminion-co]

Instead of writing it to the config.php just have it as an core app setting, we could later built an OCC command around it (listing + dis-/enable).

do you mean here to use

$allowedProviders = $this->appConfig->getValueArray('core', 'unified_search.providers_allowed');

which is set via

./occ config:app:set --value '["files","settings"]' --type array core unified_search.providers_allowed

@susnux

[artonge]

Looks good to me. Could you answer my previous question? #48841 (review)

[printminion-co]

Looks good to me. Could you answer my previous question? #48841 (review)

Not sure what "endpoint" mean.
Do you mean the API call of /ocs/v2.php/search/providers will deliver reduced providers? If so yes, one can observe it in the screenshots in PR description.

[artonge]

Not sure what "endpoint" mean. Do you mean the API call of /ocs/v2.php/search/providers will deliver reduced providers? If so yes, one can observe it in the screenshots in PR description.

No, I meant if you make requests to the search controllers, I suspect that disabled providers will still answer results.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[printminion-co]

Not sure what "endpoint" mean. Do you mean the API call of /ocs/v2.php/search/providers will deliver reduced providers? If so yes, one can observe it in the screenshots in PR description.

No, I meant if you make requests to the search controllers, I suspect that disabled providers will still answer results.

You are right... ..the GET call to "disabled" controller /ocs/v2.php/search/providers/settings/search?term=f&from=%2Fapps%2Ffiles%2Ffiles still delivers a result.

I should also disable it

[printminion-co]

Not sure what "endpoint" mean. Do you mean the API call of /ocs/v2.php/search/providers will deliver reduced providers? If so yes, one can observe it in the screenshots in PR description.

No, I meant if you make requests to the search controllers, I suspect that disabled providers will still answer results.

I moved the logic into the loadProviders Method

Now API call to disabled provider delivers same response as request to not existing search provider e.g. ocs/v2.php/search/providers/foo/search?term=f&from=%2Fapps%2Ffiles%2Ffiles

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>failure</status>
  <statuscode>996</statuscode>
  <message>Internal Server Error
</message>
 </meta>
 <data/>
</ocs>

[nfebe]

The admin documentation should mention somewhere that this is possible and how! Nice to have is probably a new follow issue covers the complete implementation of the occ command with list and dis/enable features.

[artonge]

Looks good @printminion-co. Can you rebase?

[printminion-co]

Looks good @printminion-co. Can you rebase?

rebase done

• da9d705...8e57004 feat/config_unified_search_providers_allowed