sonata-project / SonataUserBundle

Symfony SonataUserBundle
https://docs.sonata-project.org/projects/SonataUserBundle
MIT License
341 stars 487 forks source link

Add the ability to disable global_search #1683

Closed BillyMorgan closed 6 months ago

BillyMorgan commented 7 months ago

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:

  sonata.user.admin.user:
    class: Sonata\UserBundle\Admin\Model\UserAdmin
    arguments:
      $userManager: '@sonata.user.manager.user'
    autowire: false
    autoconfigure: false
    tags:
      - name: sonata.admin
        model_class: Entity\User
        group: sonata_user
        manager_type: orm
        global_search: false
        label: users
        translation_domain: SonataUserBundle
        label_translator_strategy: sonata.admin.label.strategy.underscore
        icon: <i class='fa fa-users'></i>

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.

VincentLanglet commented 7 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:

BillyMorgan commented 7 months ago

@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.

VincentLanglet commented 7 months ago

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.

Good point, does https://github.com/sonata-project/SonataAdminBundle/pull/8170 would solve your issue ?

BillyMorgan commented 6 months ago

Certainly looks like it would help :)

VincentLanglet commented 6 months ago

I release 4.30.0 from SonataAdmin so I think we can close this now