Remove navigation handler from alerting public plugin in favour of viewInAppRelativeUrl #149608
Labels
Feature:Alerting/RulesFramework
Issues related to the Alerting Rules Framework
Team:ResponseOps
Label for the ResponseOps team (formerly the Cases and Alerting teams)
technical debt
Improvement of the software architecture and operational architecture
Comments
mikecote
added
Team:ResponseOps
|
Pinging @elastic/response-ops (Team:ResponseOps) |
github-project-automation
bot
moved this to Awaiting Triage
in AppEx: ResponseOps - Execution & Connectors
mikecote
added
the
technical debt
mikecote
moved this from Awaiting Triage
to Todo
in AppEx: ResponseOps - Execution & Connectors
mikecote
added a commit
that referenced
this issue
Feb 16, 2023
…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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After #148671 merges, we have a single function in the rule type that can generate navigation URLs for a given rule type. This URL will be used in rule action templates via
{{rule.viewInAppUrl}}and also be provided to the UI via theviewInAppRelativeUrlfield in the rule API response. This relative URL is currently used in the UI as a fallback whenever the view in app functionality cannot find registered context for navigation (see alerting public plugin).From what I saw, only three plugins make use of this public plugin API (ML, ES Query and Astros in example plugin) and can easily move to the new
getViewInAppRelativeUrlfunction in the rule type. This will allow us to reduce the codebase used for navigation while also having a source of truth serving the UI and backend.The text was updated successfully, but these errors were encountered: