What it does

avo-dynamic_filters

Give the people using your admin a way to cut a crowded Index view down to the handful of records they're after, stacking conditions however they need, without you writing a scope for each one. Mark a field filterable: true and it becomes a filter, auto-mapped to the right control for its type: :text, :number, :date, :boolean, :select, or :tags. Each type carries its own conditions, so text gets contains and starts-with, dates get is-within and on-or-before, and numbers get the full set of comparisons.

Pin the filters your team reaches for every day and they wait in the bar before anyone opens a menu. Turn on inline filters and their controls sit right in the bar, so checking today's urgent tickets is a status chip, an Urgent button and a date preset, with the table updating as each one is picked.

Queries run through Ransack, so you whitelist columns with ransackable_attributes and filtering rides on the layer you already trust. Several values on one filter match any of them, a negative condition like Is not excludes all of them, and different filters narrow each other. When a plain field isn't enough, declare a dynamic_filter with your own label, query lambda, and query_attributes to reach across associations or into JSON columns. Your agent flags the fields; the filter UI, the Ransack whitelisting, and the edge cases come with the gem.

What you get

A working filter from a single flag: mark a field filterable: true and the right control for its type is wired up for you, no input to build
The conditions people actually reach for, ready out of the box: contains / starts with / is blank on text, is within / on or before on dates, the full comparison set on numbers, plus boolean, select, and tags
The filters your team uses every day, already waiting: pinned: true keeps a filter in the bar, ready before anyone opens "Add filter"
A dropdown that fits each type and filters as people click: a checklist for a select, Yes and No buttons for a boolean, date presets like Today and This month, and no Apply button. Turn it on with config.dynamic_filters.simple_filters = true
Controls right in the bar when opening a menu is one click too many: config.dynamic_filters.inline_filters = true lays every pinned filter out as chips, buttons and date ranges
Confidence that stacked filters mean what users expect: several values on one filter match any of them, Is not and Does not contain exclude all of them, and different filters narrow each other
A way to reach the data a checkbox can't, when you need it: declare a dynamic_filter with your own label, query lambda, and query_attributes pointed wherever the value lives
Filtering on data that sits a join away, across belongs_to and has_many associations or inside JSON columns, via query_attributes or a custom Ransack query
Room to make each filter fit the resource: override its label, icon, type, conditions, suggestions, fetch_values_from, or apply-on-select, and set the button label and always-expanded default once in an initializer

Why it pays off

Ship a full filter UI this afternoon by flagging fields, instead of generating Ransack queries, per-type inputs, and condition dropdowns in every app.
Filtering is all edge cases: date ranges, null handling, association joins, OR/AND combination, ransackable whitelisting. Those decisions are already made here, vetted across hundreds of apps.
Built for many apps, so it handles the conditions a filter form written for one app does not need to cover yet.
Every Avo release makes it better: filters keep working and the query layer stays maintained through upgrades, and fixes reach your app with bundle update.