Fix Map bounding box controls

[panda01]

Changes the push filter to instead also modify if there is already one.
Also properly set the title for visualizations.

Fixes #3731.

[panda01]

This in my experience has never been undefined, it's usually 'New Visualization' when I would expect that, put the OR for safekeeping.
Added this when I thought the filters were panel specific and started implementing this for that, found out they weren't and left this piece for the future since it shouldn't be undefined anyway.

[rashidkpc]

Currently this overwrites the entire filter object. It actually overwrites all geo filter objects. So couple things:

• Don't overwrite disabled or pinned filters
• If the user sets an alias on the filter, preserve the alias

[rashidkpc]

Also get rid of that title, it just duplicate's the data shown elsewhere in the UI

[panda01]

I've addressed your concerns @rashidkpc, I couldn't reproduce the overwriting of pinned filters, but everything else has been corrected.

[rashidkpc]

Unfortunately I don't think you can keep all of the meta key as it links to the index pattern, you'll end up with filters referencing the wrong pattern. You can keep all the rest, but you need to replace the index pattern with the right one

[panda01]

Hmm, so should I check and make sure they're the same index pattern?I figured if checking to make sure they're the same doesn't matter, neither does overwriting it.

Also, what do I do in the ui to make it change?

[rashidkpc]

@panda01 yeah, my mistake on the pinned filters thing.

[rashidkpc]

So there's an interesting behavior here that I'm not sure how to handle.

1. Filter to a section of data
2. Now select a section of the map you know had data before the filter, but doesn't now.
3. Data will appear

Feels like a weird interaction, filters usually only filter down. It sort of seems like we should always be fitting the new filter within the bounds of the old one right? Maybe I'm just being pedantic. @tbragin can you help me out here?

[tbragin]

@rashidkpc kpc @panda01 I checked out the PR and played with the current implementation.

In trying to think of user's expectations, when they add multiple filters to a geomap, there are three scenarios I can imagine:
(1) Successive drill-ins within the same region
(2) Replacing an existing filter with another one, but not always trying to successively drill-in
(3) Trying to select multiple filters, expecting them to add up (union of multiple rectangles)

The current implementation accomplishes (2), Rashid is asking whether we should actually be doing (1), and someone else reading this ticket may wonder if we in fact should be doing (3).

Either way, some minor issues I see with the current approach are:

• User has to anticipate how replacing one filter with another works -- basically every time you add a rectangle filter, the previous one is invalidated, and as discussed above, they may expect something different, like (3)
• There is no visual cue that one of the currently selected filters is replaced by another, replacement just happens and in a busy dashboard you may miss that fact
• There is no indication when the user makes a selection that is not a successive drill-in that there is data underlying that selection. Could we show the data we are currently filtering out as a partially transparent overlay while the user is making another selection? But not sure that's the right approach, this could also be jarring and probably computationally expensive.
• There is no opportunity for a user to cancel this action. I'm actually ok with that, doing anything else will add extra clicks, but just noting here as not everyone may actually be interested in invalidating the previous filter.

As @rashidkpc notes, we could constrain the behavior and require successive drill-ins, but:

• This would add extra clicks for any user trying to accomplish (2)
• We'd have to add visual cues to let the user know about the constraint, i.e. somehow indicate to the user why we are rejecting a filter outside of the current drill-in, rather than just not showing any data silently. For instance:
  • Could we gray out the rest of the map, so it's clear that the only place to drill in is in the region already selected?
  • If someone still tries to select outside this region, could we make the rectangle red, as an indication that the user is doing something wrong?
  • If someone does select another rectangle, should we throw an error?

All in all, i'm probably ok with keeping (2) assuming we make it more obvious to the user what's happening there, and re-evaluate if we get negative feedback. Is there any world in which we would consider doing (3)?

[panda01]

Could we show the data we are currently filtering out as a partially transparent overlay while the user is making another selection?

I think that the showing of partially greyed out buckets would be very useful, however it isn't very reliable because that information depends on a request to es which could be plagued with all kind of issues on the wire taking away from the experience.

Is there any world in which we would consider doing (3)?

I would be down for this if this is possible with elasticsearch, in my looking at the docs, i couldn't find a mention of it, and the structure doesn't make it look doable

I do think that we should give some sort of indication to the user that their current action will overwrite what ever filter they have set. Maybe even something as simple as a caution icon next to it, or in place of it on hover, with some tooltip text for help.

[panda01]

@tbragin @rashidkpc IMO we should put some kind of indicator on or around the filter icon that give information on hover since that is really one of the more viable solutions, should I move forward with that, I'm completely open to better suggestions!

[thomasneirynck]

I agree with @tanya. it is not entirely clear what behaviour we exactly want. There is also the possibility that we want panning/zooming to automatically adjust the filters (cf. #8087).

For those reasons, I'm closing this for now. We're also looking at an overhaul of the map so we can revisit #3731 and this PR in that context.