Inline Operator filter and allowFilterExpressions

[Crack]

Hello,

I have a few issues with how filter editor behaves when inline operator and allowFilterExpressions enabled. All tested on https://www.smartclient.com/smartcli...OperatorFilter (v12.0p_2018-06-07).

Bug 1
Inconsistent bahavior of clearing expression field after operator change.
1. Set Capital filter to is blank - filter value is set to empty with allowFilterExpressions=false and left with allowFilterExpressions=true. Ok, seems like changing operator diesn't make me lose my entered expression.
2. Make sure there is a value in Capital filter field. Change operator to default - filter value is always set to empty.
When I use allowFilterExpressions expression was retained in 1., so it should be retained when I switch operators in 2.
Another use case:
1. Change operator of Area to is blank.
2. Enter expression: ">100" and press enter.
3. Filter is applied but expression is cleared from input field.


Bug 2
Inconsistent application of filterOnKeypress. Set allowFilterExpressions: true, filterOnKeypress: true and:
1. Change "p" in Capital filter to "h" (ok - filter applied)
2. Change operator to starts with (bad)
3. Change value to "o" - filter is still not applied (bad)
4. Add another "o", to have "oo". Now filter is applied. (ok)
5. Change value back to "o" - filter should be applied, but it doesn't happen. (bad)
6. Change value to "" - now filter gets applied. (ok)
7. Change operator to is not blank - grid reloads, so it applies filter. Changing to is blank also applied filter. (ok)

[Isomorphic]

We'll take a look at these today - but a couple of things:

1) a filter value is not necessarily an expression - that's only true if the value contains the symbol for some operator
2) expected behavior is to clear the filter value when switching between incompatible operators (or between fields of different types in a FilterBuilder) - the blank/null variants require no value, and all other operators do, so the value should always be cleared when switching to or from one of those variants.

We'll update here when we've investigated.

[Isomorphic]

There were a couple of subtle logic problems, related to switching to and from ops that need no value and some internal logic to auto-detect partial expressions.

Those are fixed for builds dated June 9 and later.

[Crack]

Thanks, now filtering is consistent.

[Crack]

A few more related issues Tested on https://www.smartclient.com/smartcli...OperatorFilter with allowFilterExpressions: true and filterOnKeypress: true.

1. Area: enter "^2". starts with is unavailable in dropdown, but applied. Same with ends with (eg. "6,") and "!@",with the last one actually breaking filtering for good (requires page reload to fix).
2. Capital: entering "=(Oslo|Ottawa)" enables is one of, which is unavailable in dropdown, but at first properly filters grid, and then quickly reloads it and removes all results.

[Isomorphic]

The drop-down list is just the default set of operators, not the definitive list - therefore, some operators will work when typed in, and will then be added to the menu dynamically.

However, it's true that some operators genuinely are unavailable for some types and, in that case, the input value is considered to be a literal search value - in your case the literal value "^2", which is then filtered with the current operator, in this case equals, the default for numeric fields.

We see no problem with typing "!@" - it works as expected and as described just now, and doesn't cause any permanent criteria - you can just remove it again and the rows reappear..

Note that, for those examples, you can see what's happening by just opening the Developer Console and inspecting the RPC tab, to see the criteria being sent to the server.

On your final point - we don't see the behavior you report, when reloading occurs, but we do see the same behavior as for all of the other cases - the input is being considered to be a literal value, which you can see from criteria - but that behavior, in this case, is not necessarily expected, so we'll take a look and update here when we have more information.

[Crack]

Can you retest "!@" with allowFilterExpressions: true? What you are writing, that is - criteria returning to normal, does happen when I use this showcase example with its default configuration, but breaks exactly as I described when both of these flags are set. On top of that the checkbox next to "equals (default)" is still checked, which is invalid because the active filter is different.

Steps to reproduce:
1. Add allowFilterExpressions: true to inlineOperatotFilter.js and click Try It
2. In Area, enter "!@", press ENTER. Request is sent with {fieldName:"area", operator:"notEndsWith", value:null}, which is correct. But when I use right mouse button to display context menu for Area, "equals (default)" is checked as an active filter, which is wrong.
3. In Area, enter "==2", press ENTER. Request is sent with both {fieldName:"area", operator:"notEndsWith", value:null} and {fieldName:"area", operator:"equals", value:2}, resulting in empty data set.

Tested with "v12.0p_2018-06-22/AllModules Development Only". Browsers: Chrome 67, Firefox 60.

[Isomorphic]

"notEndsWith" is a string operator and not valid for numeric fields.

What you're seeing here is that filter-expressions are allowed, and one is detected - but it's invalid for the type so can't be edited in the editor's formItem - canEditCriterion() returns false.

When criteria are provided to a grid, in any of the various ways, such uneditable criteria are retained internally in the filterBuilder and applied silently, so as not to be lost.

In this particular case, the criteria is provided by the user typing into the editor, and the editor doesn't support notEndsWith - so the criteria should just be discarded, in this case, the operator cleared and the criteria never sent to the server.

This means that the "default" in the menu is actually correct.

We'll update here once we've made appropriate changes.

[Crack]

It's not valid, but client applies it when entered and in at least some cases such unsupported operators seem to work, at least partially - eg. startsWith. That's why I assumed that it should work.

An unrelated issue - https://www.smartclient.com/smartcli...adaptiveFilter is broken, throws java.lang.ClassCastException when I enter anything into SKU filter.

[Isomorphic]

Right - the problem was that we were allowing criteria for an invalid operator to be accepted in the first place.

startsWith works with text-based fields, not numbers. If you're thinking of the SKU field in the adaptiveFilter sample, that's actually a text field, although it's values are numeric.

We don't see the issue you reported with the adaptiveFilter sample - please retest since there's a new build running there now.

For the other issues, you can retest with today's build, which includes some changes to better deal with this.

Note that the isOneOf issue is not yet resolved - that's a subtle issue around the format of the value when it's in an expression, versus being displayed with the operatorIcon.

[Crack]

Any updates on isOneOf? Another cases seem to work correctly, but I'm waiting for all issues to be resolved before asking QA to retest.

[Isomorphic]

It isn't clear that we should be supporting isOneOf when operatorIcons are visible - however, if that's the case, we shouldn't accept it as valid either.

We'll take another look today and get back to you.

[Crack]

It would be nice if operatorIcons didn't limit available expressions.

Currently:
1. When I paste "=(Oslo|Ottawa)" with allowFilterExpressions and press ENTER - filter is applied correctly
2. When I paste "=(Oslo|Ottawa)" with allowFilterExpressions+filterOnKeypress - SC sends two sebsequent requests: inSet with value = ["Oslo", "Ottawa"] (correct), followed directly by inSet with value = "Oslo,Ottawa" (invalid) - filter is not applied correctly, grid is empty.

[Isomorphic]

Yes, we do see what you're reporting, although the double fetch is a separate matter - if you filtered a second time manually in any case, it would also fail, in the same way, due to differences in the format of an expression-value and a display-value in an LG editor for this operator.

That's what we're looking into - we'll update here shortly.

[Isomorphic]

We've made some changes to better support valueType: "valueSet" operators, like inSet - you should see things working consistently and as you expect for these operators in builds dated July 18 and later.

Note that while you will now see the same, correct behavior with filterOnKeypress set to true or not, you shouldn't set it if you want to allowFilterExpressions: true - if you do that, the expression is re-evaluated every time you press a key and that doesn't make sense for most operators. In most cases, you'd have to paste the entire new value into the field in one go, or type it super-fast.