[filter bar] Init filter editing

[jbudz]

Edit filters using a JSON editor. Validation is not performed on the filter object.

Closes #1583

[rashidkpc]

Currently if the JSON is invalid, clicking Done will succeed, but all of the user's changes will be lost. Can we disable the done button if the JSON isn't valid at all?

[rashidkpc]

We should continuously validate the form and disable the Done button whenever the JSON isn't valid, then we shouldn't need the try/catch.

[rashidkpc]

@jbudz Few comments, passing back to you

[jbudz]

@rashidkpc Updated

[rashidkpc]

Few more comments.

1. Can you add a message next to the disabled Done button that says Could not parse JSON input
2. If the filter is not one of the mapped types, the display of the filter stays the same, eg if you replace a filter that appears as say bytes: 30 with a bool filter containing something totally unrelated, the display will still say bytes: 30
3. If you then refresh (cmd-R) the page, the filter bar will disappear, but the filter will still exist.

[tbragin]

One big use case for filters is combining them into arbitrary predicate logic. While this is not possible directly from the UI perspective in this phase, one can achieve this by editing the filter directly (see examples below). The only drawback is that the filter name remains unchanged when you paste in a completely different filter.

Some future directions we’ve discussed post 4.3 include:

• User-configurable aliases for filter names Custom Label for filter_bar filters #5194
• Ability to add a new filter explicitly in the UI, w/o having to click on a vis or a plus sign (may need to rework the filter bar) Ability to add a new filter explicitly in the UI #5250
• Structured inputs for filters (for date, string, number as common types) Structured inputs for editable filters #5249
• Explicit support for OR, AND, NOT Multi-select (OR) dashboard filtering #3693

OR

{
  "bool": {
    "should": [
      {
        "term": {
          "geoip.country_name.raw": "Canada"
        }
      },
      {
        "term": {
          "geoip.country_name.raw": "China"
        }
      }
    ]
  }
}

AND

{
  "bool": {
    "must": [
      {
        "term": {
          "geoip.country_name.raw": "United States"
        }
      },
      {
        "term": {
          "geoip.city_name.raw": "New York"
        }
      }
    ]
  }
}

NOT

{
  "bool": {
    "must_not": [
      {
        "term": {
          "geoip.country_name.raw": "United States"
        }
      },
      {
        "term": {
          "geoip.country_name.raw": "Canada"
        }
      }
    ]
  }
}

[acs]

@tbragin "User-configurable aliases for filter names" is the same than #5194?

[tbragin]

@acs indeed, seems to be the same idea, i updated my comment above

[rashidkpc]

Talked to @jbudz. This LGTM but I agree with @tbragin and @acs that it could be much more awesome with #5194, which should be a small change. We're going to try to get #5194 into 4.3.0

[spalger]

Generally, with external event emitters you need to call $scope.$digest() or something similar. Is that not the case here?

[spalger]

@jbudz functionally things work great, I do think that the editor belongs in a directive though, one that communicates it's validity and value to a containing form using an ngModelController. This way the transition to more complex forms will be smoother.

Another option is to put this transition off until we move to more complex editors. Either way, LGTM!

[rashidkpc]

I agree it would be handy to have this in a directive that sets validity properly. I'm actually surpised ui-ace doesn't do it, but indeed, it does not: angular-ui/ui-ace#45. Tossing back to @jbudz

[rashidkpc]

Can you move this to an attribute option? This would allow us to reuse this validator elsewhere in the app, eg <textarea ng-model="myObject" require-keys=false>

[rashidkpc]

This should be true