fix(unified-search): prevent provider disabling on content filter apply

[nfebe]

When date range or person filters were applied, providers that didn't support these filters were automatically disabled in the UI. This made the in-folder filter appear auto-applied and prevented users from searching non-compatible providers.

Remove automatic provider disabling logic from updateDateFilter(), applyPersonFilter(), and removeFilter(). Content filters now apply only to compatible providers via existing compatibility checks while keeping all providers available for selection.

[susnux]

Not checked now but is it communicated to user?
So if I enable a filter and a non compatible provider is the filter de-activated or somehow shown as in-active?
I expect confusion of users if filters are selected but not applied because the provider does not support it, meaning the users should know that it is not applied.

[nfebe]

Issue

When users apply date/person filters in unified search, these filters only work on providers that support them. Other providers still return unfiltered results (Previously we tried to avoid sending the search query to these providers at all and this PR will not remove that behavior).

Example: Search "photo" with "Last 7 days" filter

• Files: Returns photos from last 7 days
• Comments: Returns ALL comments with "photo" (ignores date filter)

Question

What's the expected behavior?

A) Current: Mixed results
Show both filtered and unfiltered results together

B) Hide incompatible
Only show results from providers that support the filter

C) Visual separation
Show all results but clearly mark which are filtered vs not

Any recommendation from @nextcloud/designers

Cc: @kra-mo

[nfebe]

Not checked now but is it communicated to user?
So if I enable a filter and a non compatible provider is the filter de-activated or somehow shown as in-active?
I expect confusion of users if filters are selected but not applied because the provider does not support it, meaning the users should know that it is not applied.

Yes man you are on track! I was going to add a comment for designers, my initial solution was not to send these queries at all, it seems that might be problematic because the filter is an ad-on to the SEARCH QUERY.

So even though filters are meant to REDUCE results that are already VALID for the SEARCH QUERY in this case we are preventing a search completely for unsupported filters which makes it seem as though there are not results for the SEARCH QUERY to start with.

[kra-mo]

What's the expected behavior?

C is probably the best. But I don't think they need to be separated that clearly given it'd probably be pretty confusing. I'd just show filtered results first, then unfiltered below.

[nfebe]

A	B

[jancborchardt]

I’d agree with @kra-mo that C) is probably best, given the current situation.

But in the long run, can’t we require from search providers that they support these filters? E.g. date should be supported by all, as it’s relevant for all. Same with people, if it’s shared with them.

[kra-mo]

@nfebe Not sure what you're asking/what the actual difference is there. Could you clarify?

Regardless, the → arrow icons seem weird before the app name. Could the actual icon be shown there? If not, could the arrows at least be made smaller?

And the wording could be trimmed down significantly:

Additional results
Some selected Filters may have been ignored for additional results

Is quite long, and probably incorrect. It could just be a single line:

Partial matches

[nfebe]

@nfebe Not sure what you're asking/what the actual difference is there. Could you clarify?

It's just an preview of your implemented recommendation for you feedback. Not a question.

Regardless, the → arrow icons seem weird before the app name. Could the actual icon be shown there? If not, could the arrows at least be made smaller?

That is unrelated I will send a seperate PR and even app priorities as most users are never searching for apps, some apps results must be shown first.

And the wording could be trimmed down significantly:

Additional results
Some selected Filters may have been ignored for additional results

Is quite long, and probably incorrect. It could just be a single line:

Partial matches

Done.

[nfebe]

/compile

[nfebe]

/compile

[nfebe]

/backport to stable32

[nfebe]

/backport to stable31

[nfebe]

/backport to stable30

[jancborchardt]

But in the long run, can’t we require from search providers that they support these filters? E.g. date should be supported by all, as it’s relevant for all. Same with people, if it’s shared with them.

@nfebe can we keep this as a follow-up too?