Clarification
# avo-2
a
Clarification question: on the Users page in the demo, can you clarify the difference between the "Search" bar, the "+ add filter" button on the left and the "filters" button on the right? https://main.avodemo.com/avo/resources/users
l
Hi @adorable-france-99527 You can utilize the search bar to look up records throughout the entire table across all pages. The search parameters can be customized on the resource. https://docs.avohq.io/2.0/search.html#enable-search-for-a-resource The filters on the right are the static filters, you can configure the type of filter you prefer, the display options, and the actions to be taken when applying the filter. https://docs.avohq.io/2.0/filters.html The Add filter on the left is an Avo3 feature, providing dynamic filters that allow to apply of various filter during runtime. You only need to specify which field is filterable for the resource. Avo3 is not released yet, we're aiming to open a public beta soon
a
I'm in the 3 beta, so that makes sense - I noticed the documentation about integrating the two eventually. Is the goal to use the dynamic filters interface or the basic filters interface in the future?
And is there a thought to consolidate search and filters at any point?
or more specifically, if i wanted something that would display the regular index interface, but scoped to whatever the
self.search
was defined as on the resource, would I have to create my own custom basic filter?
@loud-jewelry-99127 i.e. the use case I'm thinking of is we want to "filter" the users table by everyone with the name, email, or username "john" and rather than having them show up in the search flyover, I'd just want to see those users in the User index
l
I'm not sure if I understand your question. You want to get on the page and be able to filter for all records that name, email or username contains "john"?
WIth the static filters you'll be able to do that by creating 3 filters, 1 for each attribute, name email and username than apply the "john" to all of them Or you can create 1 filter that apply the where clause to all wanted attributes. Example (not tested):
Copy code
ruby
class NameEmailUsernameFilter < Avo::Filters::TextFilter
  self.name = "Name email or username filter"
  self.button_label = "Filter by name / email / username"

  def apply(request, query, value)
    query.where("name LIKE ? OR email LIKE ? OR username LIKE ?", "%#{value}%", "%#{value}%", "%#{value}%")
  end
end
With dinamic filters you need to add one by one
@adorable-france-99527 let me know if this responds to your question or not
a
@loud-jewelry-99127 I think the answer is "create a custom filter" - I like the site-wide search box at the top of the interface, but I feel like there's a more common use case of wanting to do a simple 'search' which is really intended to limit the result set on the index (i.e. a filter)
l
Ah, the "search" that we provide have a different porpoise, you'll search when you want to go to that records show view If you want to limit the result on the index we have the filters. But i think i understand what's your point... That would be interesting than on each new char added to the search the index refresh with the results
That would be a whole new feature
We are still in the process of figuring it out, and each one of them has its own set of positive and negative points.
a
@loud-jewelry-99127 I don't even think it needs to update on keypress - my point is more that (I think) there's a pretty common use case of wanting to "limit" the result set with an arbitrary string, and having a common filter like that would be useful. It could even use the same search definition for the resource.
l
Hey @adorable-france-99527. So we basically have three ways of filtering out records, but each one is different in it's own way and can be used for different scenarios. and all of them can be improved 🙂
the search is your way to find a record based on very granular conditions
that search can be on a resource base or global
standard filters ar again very granular and can be stacked with other filters. that is even more granular in my mind because you can have multiple standard text filters and scope them on some record condition (products that are published and products that are not published). you can go wild with that
dynamic text filters are a dynamic way to give the power to the user and build the query how they need it with multiple columns