[alerting event log] change SO references in event log entries to single from nested

[pmuellr]

Currently the saved object reference mapping for event log entries is nested, allowing multiple saved objects to be associated with a log entry. This seems like it could get complicated though. We probably want to change this to just allow a single reference to a saved object.

Part of the thinking in using a nested property was to handle the case tracking hierarchical references. Eg, an alert runs, schedules actions to run, and the actions are run. It would be nice to associate the event log entry with the action being run, with both the action and alert. It seems like there are probably other ways of handling this; eg, writing two event log entries that can be used to make the association; or perhaps we could have a "parent" saved object reference and treat the existing one as the "primary" reference. In such cases, traversing the chain would be slower (multiple ES calls), but it's likely this might only be needed for ad hoc exploratory purposes anyway.

[elasticmachine]

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

[pmuellr]

A couple of random thoughts I had on this.

• it would be super-nice to be able to encode an SO reference as a single string; basically, a url scheme for an SO that would include space, type, and id. Eg elastic-saved-object:{space}:{type}:{id}, or similar. Would keep us from having to create an ES object to contain the various pieces. Some issues are: how to make it future proof (eg, what about "shared" SOs, what are the constraints on space ids, etc), and how to deal with cases where the SO reference we get may already have an embedded type (eg, we may get a reference to an action that is action:8ae9321e-dd1e-4ab9-868a-0bd4d0ccdd17, which is already kind of a uri-shaped thing, so we may require clients to pre-parse the SO for us, or provide an option when referencing such things that the type is already embedded)

• instead of supporting multiple SO references, it would probably be "good enough" to support a single reference (eg, to an action), and a "parent" reference (to the alert that scheduled the action). That was kind of the original intent of having multiple, to allow these kind of "relations" when doing searches, and I think probably a single level of "direct SO" and "parent SO" would go a long way to providing search assistance.

[pmuellr]

it would be super-nice to be able to encode an SO reference as a single string

I'm not sure we need to encode the space in the string - thinking we don't right now anyway. Even with "shared saved objects", I don't think that we're considering that an alert in one space could run an action in another space. The alert or action could be shared, but they would need to be visible in whatever space the alert/action is created/run.

So that boils down to {type}:{id}, but I think that's already the "standard" SO key value, so ... maybe there's not really anything to do? Just expect that the SO references that we're passed have to be in {type}:{id} form. As a singe string. Which would easily allow us to map these as an array, without having to use nested ES properties.

OTOH, SO itself separates type / id in the references property, and includes the name. Guessing the name isn't applicable to our uses (but could be nice), and so I'm wondering why they have them separated here.

[mikecote]

Added the blocked + discuss label. We'll need to discuss how we want to approach this before working on it.

[gmmorris]

A note regarding this issue that came up while working on #62015

When we query for the events that relate to a specific Saved Object we only verify that the user has permissions for that SO, but events can currently reference more SOs which we don't verify - if we decide to keep the ability to reference multiple SOs then we should address that hole.

[mikecote]

I'm going to close this issue, after discussing with @pmuellr we couldn't come up with a use case that would require a structure to only have a single saved object. In regards to linking events and such, this can be deferred to a future time as it would only require additional attributes to the mappings.