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.

Sign up for GitHub

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

Jump to bottom

[ResponseOps][Actions] Add mustache variable to link back to the rule that created the alert #145132

Closed
2 tasks done
jonathan-buttner opened this issue Nov 14, 2022 · 4 comments · Fixed by #148671
Closed
2 tasks done

[ResponseOps][Actions] Add mustache variable to link back to the rule that created the alert #145132

jonathan-buttner opened this issue Nov 14, 2022 · 4 comments · Fixed by #148671
Assignees
@mikecote
Labels
enhancement New value added to drive a business result Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@jonathan-buttner
Copy link
Contributor

jonathan-buttner commented Nov 14, 2022 •
edited by maryam-saeidi
Loading

Add a new mustache variable that injects the url to the rule that generated the alert. Ideally this would link back to the solution who registered the rule type. As a first phase we will link back to the stack management page for all rule types. In the future we can require that the solutions specify their plugin's URL path when registering a rule type. We can switch out the functionality of the mustache variable without a migration once latter solution is implemented.
@jonathan-buttner jonathan-buttner added enhancement New value added to drive a business result Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Nov 14, 2022
@elasticmachine
Copy link
Contributor

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

@jonathan-buttner jonathan-buttner mentioned this issue Nov 14, 2022
Merged
@jonathan-buttner jonathan-buttner mentioned this issue Nov 14, 2022
Closed
jonathan-buttner added a commit that referenced this issue Nov 15, 2022
@jonathan-buttner @XavierM
[ResponseOps][Rules] Adding rule.url variable (#145035)
2180a8a 
This PR adds a new actions variable for linking back the stack
management rule page. In a future PR we will require the rule type to
specify the plugin's path when registering the rule type that way we can
link back to the specific plugin that created the rule.

Issue: #145132

<details><summary>Mustache variable</summary>


![image](https://user-images.githubusercontent.com/56361221/201212197-48577715-954b-463d-9164-5d2ebfc18cb4.png)


![image](https://user-images.githubusercontent.com/56361221/201212231-23319658-0b21-469b-a272-7c59f5caa618.png)


</details>

<details><summary>Constructed URL</summary>


![image](https://user-images.githubusercontent.com/56361221/201212322-6a4eab78-88ef-4cef-aa41-e34792a8148b.png)


</details>

Co-authored-by: Xavier Mouligneau <[email protected]>
@mikecote
Copy link
Contributor

We plan on putting this into our backlog but we would be more than happy to help and review a PR to add this capability. Even better if it can re-use or enhance the existing viewInApp URL.

@mikecote mikecote moved this from Awaiting Triage to Todo in AppEx: ResponseOps - Execution & Connectors Nov 17, 2022
@ymao1 ymao1 mentioned this issue Jan 9, 2023
Closed
@ymao1
Copy link
Contributor

ymao1 commented Jan 9, 2023

Wondering if this would be the same as the viewInApp URL that is currently defined by some rule types in the client. Also we should consider what to do for some rule types (like search source query) that already define a backlink context variable but under a different variable name.

@mikecote
Copy link
Contributor

I took a look into the UI usage (code behind "view in app" button using registerNavigation API). There is only one rule type using this feature (xpack.ml.anomaly_detection_alert) while the rest are not. The anomaly detection rule type sets a filter for jobIds in the URL. It seems this could be moved to the server side and have a single place generate a URL (UI / backend).

@mikecote mikecote self-assigned this Jan 10, 2023
@mikecote mikecote moved this from Todo to In Progress in AppEx: ResponseOps - Execution & Connectors Jan 10, 2023
@mikecote mikecote mentioned this issue Jan 10, 2023
Merged
@mikecote mikecote moved this from In Progress to In Review in AppEx: ResponseOps - Execution & Connectors Jan 26, 2023
@mikecote mikecote moved this from In Review to In Progress in AppEx: ResponseOps - Execution & Connectors Jan 31, 2023
@mikecote mikecote moved this from In Progress to In Review in AppEx: ResponseOps - Execution & Connectors Feb 15, 2023
mikecote added a commit that referenced this issue Feb 16, 2023
@mikecote @kibanamachine
Single view in app function for rule actions variables and UI page (#…
ccd78c9 
…148671)

Resolves: #145132.

In this PR, I'm adding a new function to the server-side rule type
definition called `viewInAppRelativeUrl`. This function returns a
relative path to view the rule in the proper application that will
provide more context. This relative path is used to build the `rule.url`
mustache variable for the actions (overriding the rule details page link
when defined) as well as a fallback for the UI's `View in App` button if
no navigation is registered on the front-end.

Follow up issues:
- #149608
- #151355

## ML to verify

1.  Create an anomaly detection rule from the ML application
2. Go to stack management rule details page
3. Click "View in App"
4. Ensure it brings you to the ML app properly.
5. Repeat step 1 to 4 in a space that isn't the default

Note: ML won't take advantage of the new functionality yet, but we plan
to help in a follow up #149608
so that ML anomaly detection rules can provide a view in app URL within
the rule action messages.

## ResponseOps to verify

1. Set `server.publicBaseUrl` to the proper value in your kibana.yml
6. Modify the [index threshold rule
type](https://github.com/elastic/kibana/blob/main/x-pack/plugins/stack_alerts/server/rule_types/index_threshold/rule_type.ts#L108-L136)
to have a `getViewInAppRelativeUrl` function returning
`/app/management/insightsAndAlerting/triggersActionsConnectors/connectors`.
7. Create an index threshold rule that always fires. Make sure to add a
a server log action that contains the `{{rule.url}}` variable.
8. Pull the printed URL from the server logs and make sure it works and
brings you to the connectors page.
9. Navigate to the rule details page, click the "View in App" button and
ensure it also brings you to the connectors page.
10. Create a Kibana space.
11. Go into that created space and repeat step 3 to 5. Ensure the URL
and View in App keep you in the same space.

---------

Co-authored-by: Kibana Machine <[email protected]>
@lcawl lcawl mentioned this issue Mar 20, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mikecote mikecote

Labels
enhancement New value added to drive a business result Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
AppEx: ResponseOps - Execution & Connectors
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Single view in app function for rule actions variables and UI page mikecote/kibana
4 participants
@mikecote @ymao1 @elasticmachine @jonathan-buttner