Searching limitations

[mamhoff]

I'm currently reworking Solidus' promotion system. The order admin in both the old backend and the new admin allows filtering orders by either promotion names, or by promotion code. I'm thinking about abstracting something that allows - for any resource, like and order, product, etc - defining which fields can be searched, by which fields can be sorted, and how filtering is possible.

In the solidus_backend, the table filter for orders is a multitude of mutually non-exclusive (ored) inputs. In the new admin, there's only one input field that aims to cover all the uses of the other input fields. This can be problematic for performance reasons (some input fields are really really time-consuming to search for stores with a large number of e.g. addresses, and if you know you're searching for an order number there's no need to search the addresses for R12345).

Do we have plans for supporting separate text search fields on the backend page component? Currently, there's only elaborate support for filter selects and a single search box... I'm all for helping with the implementation here, but I think we need some design input.

[kennyadsl]

Hey @mamhoff, we have something related to how search should work in the Figma files for the new admin. Does this proposal go in the same direction as you are describing?