[Uptime] Add Locations to the UI Monitor Management Table

[dominiqueclarke]

As an Uptime user, I want to be able to tell at a glance which locations my monitors are run against.

Feature description
Add a locations column to the UI Monitor management table, located at uptime/manage-monitors.

AC

• When a user visits the UI Monitor Management table, their locations are displayed under a locations column with EuiBadge components displaying the label for each associated label. The UX will be the same as the current Tags column.
• Where a user has more than 3 locations attached to a monitor, the column will display the first 3 followed by an indicator of how many extra locations are available. When clicking on that indicator, the column will row to show the full list of locations. The UX for this will be the same as the Tags column.

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[paulb-elastic]

Out of interest, will we store this in a different field to the current location that's made available from the heartbeat.yml processors (i.e. the location property is the same for monitors of either type, so a common UI could show location from the same field)?

[dominiqueclarke]

That's a great question @paulb-elastic.

We store location data on the saved object in a UI friendly format. This format directly reflects the location object we receive back from the manifest. With regards to showing the location in the management table or filtering by location, we plan to use the UI friendly format.

However, we should consider where these processors are applied in order to ensure that location is indexed appropriately on the resulting ES documents. The UI saved objects are formatted to the appropriate heartbeat.yml format before sending to the service. At this time, we are not directly formatting processors on the heartbeat.yml, but perhaps we should.

@vigneshshanmugam @andrewvc Does the service directly take care of appending location processors onto the configuration to ensure that the location is indexed appropriately in the resulting ES documents? Or should the client handle formatting the processors before sending the configuration to the service?

[andrewvc]

The service does not do this today, but we have an open task to do so. I think we should do it there, and not in the configs to reduce possible errors.