Closed BillyMorgan closed 6 months ago
If not, is the correct fix to extend the configuration to allow for the extra tag attribute?
This feel weird cause if we start adding such config, it would be expected to have
Best would be an entry point on SonataAdminBundle, if it doesn't exist already.
I see multiple solutions:
First, you can already decorate the SearchHandler https://github.com/sonata-project/SonataAdminBundle/blob/247131ee4146de523a472b061db60e3f4aeccc81/src/Search/SearchHandler.php#L24
public function search(...) {
if ($admin instanceof UserAdminBundle) {
return null;
}
parent::search(...);
}
We could have used a method inside the AdminInterface rather than using the config so https://github.com/sonata-project/SonataAdminBundle/blob/247131ee4146de523a472b061db60e3f4aeccc81/src/Search/SearchHandler.php#L41-L43 could be rewritten if
if (false === $admin->isSearchEnabled()) {
return null;
}
so it would have been easier to set the value be decorating the admin with an admin extension...
@VincentLanglet Thanks for your help and suggestions. I agree it would be a slippery slope having to allow for every potential config option.
Before I go on, please let me prefix this with an apology: Sorry, for only whinging and not offering any solutions. I'd help if I had the time but currently it's not an option for me. I feel like I need to mention this in case someone else comes along with the same issue:
First, you can already decorate the SearchHandler
It seems like you can't realistically do that with the code in it's current state. At least not without making and even bigger mess than what I have in my original "solution".
The Search handler is mentioned as a concrete class multiple times in the library (i.e. no interfaces). Even if you do decorate it by defining sonata.admin.search.handler
in services.yaml, you then need to basically clone and redefine the Sonata\AdminBundle\Block\AdminSearchBlockService
to accept the new decorated handler because the service is declared final and has a private dependency on a concrete Sonata\AdminBundle\Search\SearchHandler
.
First, you can already decorate the SearchHandler
It seems like you can't realistically do that with the code in it's current state. At least not without making and even bigger mess than what I have in my original "solution". The Search handler is mentioned as a concrete class multiple times in the library (i.e. no interfaces). Even if you do decorate it by defining
sonata.admin.search.handler
in services.yaml, you then need to basically clone and redefine theSonata\AdminBundle\Block\AdminSearchBlockService
to accept the new decorated handler because the service is declared final and has a private dependency on a concreteSonata\AdminBundle\Search\SearchHandler
.
Good point, does https://github.com/sonata-project/SonataAdminBundle/pull/8170 would solve your issue ?
Certainly looks like it would help :)
I release 4.30.0 from SonataAdmin so I think we can close this now
I'm not entirely sure if this is a bug, or a feature, or me being a dolt but I wanted to exclude the user admin from the global search and the only way I could do it was to completely re-implement the service like this:
All of this, just because I needed to add
global_search: false
. Is there already a better way to do this? If not, is the correct fix to extend the configuration to allow for the extra tag attribute? If so, I could give it a crack.