Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Alerting] extend Alert Type with names/descriptions of action variables #59756

Merged
merged 4 commits into from Mar 13, 2020

Conversation

pmuellr
Copy link
Member

@pmuellr pmuellr commented Mar 10, 2020

resolves #58529

This PR extends alertType with an actionVariables property, which
should be an object with optionial properties context and state.
These properties should be typed as optional Record<string, string>
values. The keys are the names of the relevant action variables,
and the values are the localized descriptions of the variables.

This new property is optional, for the moment.

Checklist

Delete any items that are not applicable to this PR.

TODO

For maintainers

@pmuellr
Copy link
Member Author

pmuellr commented Mar 10, 2020

I didn't realize we already had a property set up for the action variables!

export interface AlertType {
id: string;
name: string;
actionGroups: ActionGroup[];
actionVariables: string[];
defaultActionGroupId: ActionGroup['id'];
}

So, that will need to be changed, and I haven't looked, but I suspect there is already some code that will display them, so I'll fix that up too. We'll need to figure out if we want to display a tooltip for the localized description of them, or display them in some other way.

@pmuellr
Copy link
Member Author

pmuellr commented Mar 10, 2020

There are also a number of "always provided" action variables, by the alerting framework itself, like alertName, alertId, etc. I didn't provide a way to get these from the server, as they are basically static. I thought we'd just hard-code them in the UI code for now, if we think we need them from the server, we can add that later.

@pmuellr
Copy link
Member Author

pmuellr commented Mar 10, 2020

Yee Haw!

image

@pmuellr
Copy link
Member Author

pmuellr commented Mar 10, 2020

commit #728e8f69eb7e22a3b0875a2b81d20e1abadb3ec4 now displays the variables in the UI context menu

@pmuellr pmuellr force-pushed the alerting/action-vars-in-type branch 2 times, most recently from 356604c to d6c8457 Compare March 10, 2020 21:17
@YulNaumenko YulNaumenko self-requested a review March 11, 2020 16:48
Copy link
Contributor

@YulNaumenko YulNaumenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I have a suggestion regarding empty variables list to be optional as on the server. I think it should be nice do not show it in this case.

export interface AlertType {
id: string;
name: string;
actionGroups: ActionGroup[];
actionVariables: string[];
actionVariables: AlertTypeActionVariables;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to have it as optional and do not show the empty dropdown list in the case it is undefined

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

messageVariables which use actionVariables in UI is already optional for the ActionParamsProps as well, but some UI fixes still should be done to not display it. Maybe make sense to have a separate issue for this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The action variables list will never be empty by the time the context menu displays, as there are 5-6 "always available" variables that come from the alert library; eg, alertName.

I've also reshaped these since you reviewed, as the shape was radically different than actionGroups (which is an array of id / name object), so I changed the actionVariables to match. This also means we won't have prototype pollution issues (even if not our fault), as we won't be using unknown properties on objects.

resolves elastic#58529

This PR extends alertType with an `actionVariables` property, which
should be an object with optionial properties `context` and `state`.
These properties should be typed as optional `Record<string, string>`
values.  The keys are the names of the relevant action variables,
and the values are the localized descriptions of the variables.
@pmuellr pmuellr force-pushed the alerting/action-vars-in-type branch from ec74b52 to 42d9b19 Compare March 12, 2020 02:50
@pmuellr pmuellr marked this pull request as ready for review March 12, 2020 19:22
@pmuellr pmuellr requested a review from a team as a code owner March 12, 2020 19:22
@pmuellr pmuellr added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Mar 12, 2020
@elasticmachine
Copy link
Contributor

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

Copy link
Contributor

@mikecote mikecote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes LGTM! Had one question in hopes of removing the double places to maintain the default list of action variables but you have more context than I do.

I will also open an enhancement issue to use the user friendly description attributes defined within the alert action param templating.

Edit: As discussed, we'll wait and see before thinking too far ahead.

Comment on lines +25 to +26
// this list should be the same as in:
// x-pack/plugins/alerting/server/task_runner/transform_action_params.ts
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recall previously the mention of having two files to maintain. I wonder if there's a way we could move this function into a common folder and do something like _.pick({}, ...) within x-pack/plugins/alerting/server/task_runner/transform_action_params.ts based on the accumulation of name properties.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ... the common folder ... yes, that might well work.

For whatever reason I was thinking that we'd need a new server API to retrieve these.

I'll open a new issue to resolve this.

@pmuellr
Copy link
Member Author

pmuellr commented Mar 12, 2020

@elasticmachine merge upstream

@pmuellr
Copy link
Member Author

pmuellr commented Mar 13, 2020

@elasticmachine merge upstream

@pmuellr pmuellr merged commit ce1836b into elastic:master Mar 13, 2020
pmuellr added a commit to pmuellr/kibana that referenced this pull request Mar 13, 2020
…les (elastic#59756)

resolves elastic#58529

This PR extends alertType with an `actionVariables` property, which
describes the properties of the context object passed when scheduling
actions, and the current state.  These property descriptions are used
by the web ui for the alert create and edit forms, to allow the properties
to be added to action parameters as mustache template variables.
pmuellr added a commit that referenced this pull request Mar 13, 2020
…les (#59756) (#60082)

resolves #58529

This PR extends alertType with an `actionVariables` property, which
describes the properties of the context object passed when scheduling
actions, and the current state.  These property descriptions are used
by the web ui for the alert create and edit forms, to allow the properties
to be added to action parameters as mustache template variables.
@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

gmmorris added a commit to gmmorris/kibana that referenced this pull request Mar 13, 2020
* master:
  [Alerting] extend Alert Type with names/descriptions of action variables (elastic#59756)
  [Ingest] Fix data source creation and double system data source (elastic#60069)
  Add button to view full service map (elastic#59394)
  unskip tests for code coverage (elastic#59725)
  [Ingest] Add Fleet & EPM features (elastic#59376)
  [Logs UI] Show navigation bar while loading source configurati… (elastic#59997)
  [Endpoint] ERT-82 Alerts search bar (elastic#59702)
  Aggregate queue types being used by Beats (elastic#59850)
  skip flaky suite (elastic#59541)
  Convert Timeline to TypeScript (elastic#59966)
  Make context.core required argument to context providers (elastic#59996)
@mikecote mikecote added release_note:enhancement and removed release_note:skip Skip the PR/issue when compiling release notes labels Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported Feature:Alerting release_note:enhancement Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Alerting: Extend server API type AlertType with property actionVariables: string[]
5 participants