Thanks for giving this request some attention, but after having had a chance to try out the changes included in the most recent update, I have to disagree with the "completed" status of this request due to some odd logic used in the implementation.

For example, we have a fairly basic grid with some string, boolean, and enum columns, and I used the Search Panel to search for "chi" (ex. Chicago). The filter applied for the string columns was "LIKE "%chi%' as expected. What was not expected, however, was all of the boolean columns getting a filter of "= 0" applied to them. After looking at the code, the way it's handling booleans is (more or less) filtering on "= 1" if the search phrase was the string value "true", "IS NULL" if the search phrase was "null", or otherwise "= 0" for any other string search value. In other words, if you search for a string phrase that is not "true" or "null", it will return A) results where string columns contain the search phrase; and B) results where any boolean column happens to have a value of false.

Next I looked at how our enum column was handled (public enum NetGross { Net, Gross }). Searching for "n" and "g" didn't seem to cause it to filter on the enum column at all. I tried searching for "0" instead (since the underlying enum values are int, i.e. NetGross.Net = 0 and NetGross.Gross = 1) and found it now attempted to filter on the enum column, but threw an exception when running the Ajax request (due to attempting to use the GreaterThanOrEqual operator on an enum). After looking at the code, the enum grid column has a type of "number", and apparently the Search Panel uses the "greater than or equal to" operator as the default for number columns (even though this operator is not one explicitly specified when setting up the grid).

I realize that these are likely complications that came up while working on these updates, and the difficulty involved in trying to come up with a way to handle the different scenarios in a way that works well for everyone. I'm not trying to downplay any of these challenges and I'm not sure what the best way might be to handle these things, but I do not believe we're there yet. As it currently stands, I cannot use the Search Panel in my grid to search for a numeric value without it silently throwing an exception on the Ajax request (due to the enum column). This limits me to string-based search phrases, and unless the phrase happens to be "null" or "true", this also means any search I perform will also include results where any boolean columns have a value of false.

Hi Alex,

Is the team planning to take this up soon? I agree with Aaron that this is a much needed feature - I have a similar use case (with ASP NET MVC) and it is hard to explain to the users why certain fields are not searchable. I certainly want to use server operations in this particular scenario as it improves the performance significantly.

Also, I forgot to mention, we have looked into using the Filter widget as well as a few other things, and plan on using them in addition to the search panel. The great part about the search panel is the ease of use: a single place to type something in that will search across all columns. The Filter widget, by contrast, serves a different (but equally important) purpose of giving the user the functionality to apply a more specific type of filter to the results (ex. Status column equals "open" or "pending" and Updated before today's date).

Thanks for the quick response! For the silent error, something like that could be helpful. When I was testing the search panel specifically, it was pretty obvious that it wasn't working as expected since my results weren't getting filtered. Thinking ahead, however, if I were just setting up a new grid and had an invalid configuration, I wouldn't necessarily test the search panel specifically since my focus would probably be more on the data pulling through and displaying correctly (and I would assume the search panel, column-level filtering, etc. all worked fine). For these reasons, it would be nice if the grid and/or search panel configuration would be checked upfront and if there were problems, it would be very evident (ex. display an error instead of the grid, JavaScript alert, etc.). If this is what you had in mind, then yes, I think this would be pretty helpful and could help catch problems while still in development instead of after code goes into production and end-users have problems using the search panel.

 

As for expanding the configuration of the search panel, I would think that ideally, by default you would want the functionality to be the same across all types, whether server or client operations are being used (to maintain a consistent user experience from an end-user perspective). Having the ability to customize this on a per-field basis would definitely be a step in the right direction even if the functionality wasn't necessarily the same between server and client operations, because at least that way developers could still make the data searchable (and perhaps in a more useful way than what the default might offer). In a perfect world :) it would be great if the field-specific customizations could be specific to the original types. For example, it would be nice if it could be specified that a DateTime value of 08/01/2020 1:45 PM should also match on "8/1" and "13:45" (so somewhat of a "contains" type of search, with the awareness of how dates/times may or may not have leading zeros, be in 12 or 24 hour format, etc.). This would also allow a user to enter 08/01 in the search panel and see all results on that particular day (even if they don't know the exact time). I'm not sure how exactly this might be implemented, and this might be kind of an "icing on the cake" kind of thing, but I just thought I'd mention it. If the data was at least searchable (even if not this "fancy"), we could at least explain to users why entering "8/1" isn't matching on "08/01" much easier than server vs. client operations and data types.