Removed restriction on adding multiple connectors of the same action type to an alert

[YulNaumenko]

Resolve #60583

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[gmmorris]

LGTM, but I have a few clean up suggestions:

1. That reduce can be replaced with a much simpler array now that we don't need the keys. :)

2. It feels like we're relying a lot on the index not changing, which can be hard to follow as a developer new to the code. Would it be possible to create the actionsErrors inside of the actions.map (on line 431) so that we created just before calling getActionTypeForm for each action? That way, you have less "global state" in the component.

This would mean ending up with something like this:

...
 return (
    <Fragment>
      {actions.map((actionItem: AlertAction, index: number) => {
        const actionConnector = connectors.find(field => field.id === actionItem.id);
        // connectors doesn't exists
        if (!actionConnector) {
          return getAddConnectorsForm(actionItem, index);
        }
        const actionErrors: Array<{ errors: IErrorObject }> =    actionTypeRegistry.get(alertAction.actionTypeId)?.validateParams(alertAction.params);
  );

        return getActionTypeForm(actionItem, actionConnector, actionErrors, index);
      })}
      <EuiSpacer size="m" />
...

That way you're only using the index for the key, not for finding the error, which is a bit easier for me to follow, 🤷‍♂

Just some thoughts 😃

[pmuellr]

Concur with Gidi's comments.

Longer-term, we'll need a way to re-order these actions - they're stored as an array, and a customer might want to reorder them for some reason. Not needed for 7.7 :-)

[andreadelrio]

We'll need to look into a better fix for that z-index later but this should do it for now.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 66ab511

History

• 💚 Build #34964 succeeded aaea88e
• 💚 Build #34780 succeeded 26a0b09

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream