block_search_result is not compatible with Sonata 4.

[VincentLanglet]

In https://github.com/sonata-project/SonataAdminBundle/pull/7275 we deprecated the option sonata_admin.global_search.case_sensitive

And in SonataDoctrineORMAdmin, we changed the case_sensitive option to force_case_insensitivity. (And anyway, we shouldn't rely on a filter option since name could be different for different filter or different persistence bundle).

So the following code is not up to date anymore https://github.com/sonata-project/SonataAdminBundle/blob/master/src/Resources/views/Block/block_search_result.html.twig#L61-L68

CC @phansys @sonata-project/contributors, what would be the way to solve this.

[phansys]

IMO, we have no easy way to collect the result of each filter, which should be the only source of truth for this case (given the manager, its FilterInterface implementation should be responsible to tell whether the filter matches the criteria or not). In that case, I don't know if we could split the behavior for each filter (which surely will lead for multiple queries instead of just one) or if we could try adding some logic to the current query, in order to expose the columns matching the criteria. Otherwise, I think we cannot display this information in a reliable way.

[VincentLanglet]

Another thing this template doesn't take in account is that some filter can be disabled by changing the global_search value: https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/3.x/src/Filter/StringFilter.php#L155

Also, user could decide to provide a filter different from the stringFilter, enabled for the search, so the check cannot be in front for sure. Eventually, the feature could be changed to display all the filters used for the search.

In order to not delay the 4.0 release what should we do ? Removing this feature ?

[phansys]

Yes, I think we haven't a better alternative right now.