Closed phansys closed 2 years ago
We could have like a FilterBag
and fill it up if the request is there, and dispatch events that would allow people to add their own filters.
In order to start working on this, I'd like to know where this filter bag should be filled with the default values from request. The possible options I can imagine are these:
kernel.request
or similar event;getDatagrid()
, buildDatagrid()
, getFilterParameters()
, etc);CRUDController::preList()
.It can be filled at the same place the only difference would be we dispatch an event with filter bag, that would allow users to modify filter bag.
cc @sonata-project/contributors wdyt?
I've started #5549 in order to address this task. Please, let me know if the approach is something like you've proposed. BTW, with these changes I'm still not able to set custom filters with the PR #5530. Thank you.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Should we keep this @phansys ?
https://github.com/sonata-project/SonataAdminBundle/pull/6162 is enough ?
Should we keep this @phansys ?
6162 is enough ?
I don't know, but given the title in that PR, I think the goal of this issue is not yet reached. The proposal here is to be able to set admin filters on demand, regardless their default values. By instance $admin->setFilters([...])
.
Closing due to lack of interest
Feature Request
Provide a way to configure admin's filter parameters dynamically without a hard dependency against a
Request
: https://github.com/sonata-project/SonataAdminBundle/blob/b2d0f4846c8752ee3f3db1a86dff6ae7a847857a/src/Admin/AbstractAdmin.php#L761I think the request object still provide the default implementation, but IMO this must be decoupled from the filter responsibility.
Some context: I found this problem while trying to use an admin inside a block (see #5530), which based on my proposal, should not be tied to the master request since it is just part of an embedded block.