No announcement yet.
  • Filter
  • Time
Clear All
new posts

  • Inline Operator filter and allowFilterExpressions


    I have a few issues with how filter editor behaves when inline operator and allowFilterExpressions enabled. All tested on (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)

  • #2
    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.


    • #3
      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.


      • #4
        Thanks, now filtering is consistent.