I think you might be misunderstanding *why* I think there's value in the change I'm suggesting.  Please, see my comments below:

> style is currently to have these filters inline

1. I couldn't find where this is documented as the current style.
2. Also, the change I suggest relates more to design rather than style.
3. The controller's knowledge of the filter's nested data structures
   introduces complexity and tight-coupling to ```elasticsearch```.
4. I noticed that inline filters like these were in a few other controller's
   actions, which presents a good opportunity to DRY up and encapsulate the
   data structure *before* it gets too unwieldly.

> really need to extract one-liners into separate place

1. These three one-liners represent non-trivial knowledge about the data structure required to search for products.
2. The separation of concerns would benefit other controllers and their actions as well as future project maintainers and developers new to the project.
3. Providing an API would help isolate the responsibility and concerns for filtering to a separate module or class in the code base where underlying changes to any dependencies could be more easily mitigated in the future.

I left this TODO comment in my commit hoping to get this feedback here in the PR.
I'm convinced that we should make the change. Maybe not now, but soon.

If these one-liners were isolated to just this one controller or even a few action methods, I'd be in complete agreement with you, but being spread throughout a few other controllers, these one-liners engage in enough repetition and complexity that abstracting these filters **sooner rather than later** into a cohesive API will make the code more understandable,  maintainable, testable, and flexible for future changes dependencies and/or functionality.

- Does this clarify for you the line of reasoning behind my code comment?
- Given my comments above, why else might this change not be warranted?
- Why wouldn't we want a more encapsulated search/filtering API capable of hiding arrays of nested hashes sprinkled throughout the controllers?

For now I'll remove the comment and finish off this PR without my recommended changes, but I'd like to keep this discussion open and
get more feedback from you and others.  I enjoy a good design discussion so I'd enjoy hearing more of your thoughts on this. Thanks!