Connectors Stack Management tab shows 'Availability' labels that need clarification

[EricDavisX]

Kibana version: 8.4.0-BC1

• Kibana commit - 58f7eaf
• Deployed over cloud prod

Describe the bug:
The Connectors page has a new 'Availability' column that needs some coordination to get the right/best labels for all feature areas.
It lists, at a minimum 'cases', 'alerting', 'uptime', 'security_solution' and maybe more.

Steps to reproduce:

1. deploy the stack to cloud and navigate to Stack Management, then further on to 'Rules and Connectors'
2. and then on to 'Connectors'
3. see the 'availability' column there, new in 8.4

Expected behavior:
TBD, @shanisagiv1 do you have inclination to change this? @mikecote mentioned you.
We were concerned 'uptime' sounded too specific and maybe it should be a general 'observability' tag perhaps? That would be my first suggestion, but would need to coordinate with the relating team.

Screenshots (if relevant):
8.4.0 BC1 UI:

just for reference, here is 8.3.X UI:

Other info:

1. you can get a useful list of connectors populated by using the env-bootstrap 'rac' call from ml-qa framework.
2. It looks like the Availability column could be allowed to take up a little more width, safely - so it looks better on smaller screen/usage. j

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[mikecote]

I can confirm there's only 4 available values currently:

• Uptime
• Alerting
• Security Solution
• Cases

We may be able to remove Uptime from the list. If so, this would leave "Security Solution" as the odd one. If we can find a new name for this one, we could be ok. Something like "Security rules" or "Detection Engine" or something else? I'm hoping we don't have to get too specific as I could see the eventual goal to have all connectors available to all alerting rules. Leaving "Alerting" and "Cases".

[shanisagiv1]

I would suggest looking at it from the end state when there are connectors that are supported in all solutions. My suggestion is the following list:

• Security Cases
• Security Rules
• Observability Rules
• Observability Cases
• Stack Rules
• Stack Cases
• Other particular solutions (like Uptime)

If we agree on that, the question is if we can break "security solution" down to the 2 above (hope we can). Also, is the "security solution" label good enough even today? are there sec rules that support a connector that it's not supported in sec cases?

let me know wdyt. thanks!
@mikecote @EricDavisX

[mikecote]

I would like to discuss this offline if possible. I'm thinking it may be too many labels to display all at once. I was originally hoping we'd only have two tags Alerting and Cases which represent two high level features and we could consider it a bug if a solution / application doesn't support all the connectors..

[mikecote]

After discussing with @shanisagiv1, the UI should focus on two availabilities "Alerting rules" (rename) and "Cases" to keep the labels simple.

In the code, we can consider "Security solution" and "Uptime" part of "Alerting rules". We can add some logic to allow filtering in the code but they shouldn't display in the UI.

---

@shanisagiv1, @ymao1 was mentioning it may be redundant to display the "Availability" as a column in the connectors list (since it is per connector type and not connector). Any thoughts if we should remove it from there? (leaving it in the create flyout header).

[dolaru]

It seems to me that we have two bits of info that we're trying to convey:

1. whether the connector is compatible with Rules and/or Cases
2. what solutions are compatible with the connector

IMO, if we still want to keep the connector compatibility information in the connector list, it could be hidden in a tooltip triggered by hovering over a tiny button with an ⓘ label in the Type cell. If the two types of compatibility information are displayed separately, even better.

Also note that I said "compatibility" and not "availability" - makes more sense to me.

[mikecote]

Good thoughts, thanks for sharing @dolaru! I like "compatibility" as a label better.

@shanisagiv1 any thoughts with the name? And whether or not we want to display something in the connectors list?

[shanisagiv1]

makes sense to me.