[Actions] Jira, IBM Resillient & Service Now actions are coupled to alerting

[gmmorris]

Some of our actions are coupled to alerting, relying on an {{alertId}} variable in the messageVariables.

As seen here:

kibana/x-pack/plugins/triggers_actions_ui/public/application/components/builtin_action_types/servicenow/servicenow_params.tsx

Line 64 in ac18bc0

if (!savedObjectId && messageVariables?.find((variable) => variable.name === 'alertId')) {

This means you can't test or execute actions without providing this value and there is no way to provide this in the test UI.

To get around this coupling the params components we could display a field to input these values when the value can't be found in messageVariables. This would mean we still have some coupling is there, but at last it's hidden from the user.

[elasticmachine]

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

[YulNaumenko]

This code is dead:

if (!savedObjectId && messageVariables?.find((variable) => variable.name === 'alertId')) {
      editSubActionProperty('savedObjectId', '{{alertId}}');
}

Initial idea was to add back link to the alert which was created ServiceNow incident (the similar functionality that we have for a Case), but it is not relevant for now - we are not able to support this feature in alerting anyway and it definitely should be a separate issue. So under the current issue we can just remove this code. cc @mikecote

[gmmorris]

This code is dead:

if (!savedObjectId && messageVariables?.find((variable) => variable.name === 'alertId')) {
      editSubActionProperty('savedObjectId', '{{alertId}}');
}

Initial idea was to add back link to the alert which was created ServiceNow incident (the similar functionality that we have for a Case), but it is not relevant for now - we are not able to support this feature in alerting anyway and it definitely should be a separate issue. So under the current issue we can just remove this code. cc @mikecote

Ah that's good to know! But I think it might only be true for Service Now.
I understand from @cnasikas that this is still needed in Jira.

[gmmorris]

I think we should preemptively pull this in, as this needs to be addressed before 7.10 is released, otherwise we'll have a broken behavior when users try to test these three connector types.

[cnasikas]

Ah that's good to know! But I think it might only be true for Service Now.
I understand from @cnasikas that this is still needed in Jira.

I think setting this https://github.com/elastic/kibana/blob/master/x-pack/plugins/actions/server/builtin_action_types/jira/schema.ts#L40 to nullable will work for both alerts/actions and cases. In cases, we provided it, in alerts not. Be aware that Jira, Resilient, and ServiceNow have the savedObjectId property in their schema. What do you think @gmmorris @YulNaumenko ?

[gmmorris]

I took a quick looked at the actions' implementations and can't see anywhere in the server where we actually use savedObjectId in any of these actions...
Are the actions not relying on savedObjectId for anything?
If that's the case, we should do as Yul suggested and just remove it all together, no? 🤷

[gmmorris]

I took a quick looked at the actions' implementations and can't see anywhere in the server where we actually use savedObjectId in any of these actions...
Are the actions not relying on savedObjectId for anything?
If that's the case, we should do as Yul suggested and just remove it all together, no? 🤷

I take that back - they're packaged up in the subActionParams and sent as is to all three the services as part of the pushToService subAction.
Are the services not relying on this? Is it just helpful extra info? 🤔

[cnasikas]

It is extra info that services will rely on it on the feature. As @YulNaumenko said an issue could have in its description the link of the case created in Kibana. It will also help when we start to support bi-directional communication. @XavierM maybe could add more on this.

[gmmorris]

Yeah, I guess the problem here is the coupling because if these services need this then it should be passed in by the params, rather than assuming there'll be an alertId anywhere...

Long term this would be best addressed by: #66095

For the time being, to keep these actions from breaking when they execute without an Alert, we should just render a field when the alertId is missing, where the user can provide a savedObjectId

[gmmorris]

@mikecote and I have decided thatthis fix should be part of 7.10, pulling it in 👍