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

[ResponseOps][Rules] Adding rule.url variable #145035

Merged
merged 12 commits into from
Nov 15, 2022

Conversation

jonathan-buttner
Copy link
Contributor

@jonathan-buttner jonathan-buttner commented Nov 10, 2022

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

Mustache variable

image

image

Constructed URL

image

@jonathan-buttner jonathan-buttner added release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework v8.6.0 labels Nov 10, 2022
@elasticmachine
Copy link
Contributor

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

Copy link
Member

@pmuellr pmuellr left a comment

Choose a reason for hiding this comment

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

LGTM; made a comment about a comment and suggestion to add a debug log ...

`);
});

it('does not populate the rule.url when the alert id is set to undefined', async () => {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
it('does not populate the rule.url when the alert id is set to undefined', async () => {
it('does not populate the rule.url when the rule id is set to undefined', async () => {

Just to make it a little clearer :-)

`);
});

it('does not populate the rule.url when the alert id is a number', async () => {
Copy link
Member

Choose a reason for hiding this comment

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

I'm curious why we're even handling this case. Not something I think we usually test, so curious ...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah the reason I thought this was worth covering is because the way we've typed the task manager params is Record<string, any>. So when we destructure taskInstance.params it's showing alertId: ruleId as type any. So I figured it's probably worth skipping the rule building if the type is anything but a string 🤷‍♂️

image

Copy link
Member

Choose a reason for hiding this comment

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

Ah! Looking closer, I missed the buildRuleUrl() method is referencing this.taskInstance.params.alertId - I missed that before, and that does seem a little brittle. Looking at it's call site, it looks like you could instead pass ruleId as a parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I can pass it as a parameter, but just to make sure I'm understanding, that doesn't address it being typed as any right? I still need to ensure it is a string.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, good catch - ya, that variable is extracted from the same place 🤦🏻‍♂️ .

However, I noticed a this.rule available, so I think you can leave it parameterless and change

this.taskInstance.params.alertId -> this.rule.id


return ruleUrl.toString();
} catch (error) {
return;
Copy link
Member

Choose a reason for hiding this comment

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

feels worthy of a log.debug(), just in case this case gets caught, but we're confused why the url didn't get set

Copy link
Member

@pmuellr pmuellr left a comment

Choose a reason for hiding this comment

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

LGTM; made a comment about a comment and suggestion to add a debug log ...

Also a comment about using the getRuleDetailsRoute() somewhere it's not currently being used. I'm sure this would end up needing to be fixed when this code gets more plugin-specific, so doesn't seem like a biggie.

@@ -886,7 +887,7 @@ export const RulesList = ({
onPage={setPage}
onRuleChanged={() => refreshRules()}
onRuleClick={(rule) => {
const detailsRoute = ruleDetailsRoute ? ruleDetailsRoute : routeToRuleDetails;
const detailsRoute = ruleDetailsRoute ? ruleDetailsRoute : commonRuleDetailsRoute;
history.push(detailsRoute.replace(`:ruleId`, rule.id));
Copy link
Member

Choose a reason for hiding this comment

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

Is there some reason we don't use getRuleDetailsRoute(rule.id) here, as was done in rule_details.tsx above?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The ruleDetailsRoute is passed in as a prop to this component and it wasn't clear to me what the value would be. So I don't think we can rely on it equaling commonRuleDetailsRoute aka '/rule/:ruleId'. So if we called getRuleDetailsRoute here it could change the initial part of the path (/rule may not exist in the ruleDetailsRoute passed in as a prop).

Another option is that we change getRuleDetailsRoute to take the path portion but that's pretty close to just calling .replace directly 🤷‍♂️

Copy link
Member

Choose a reason for hiding this comment

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

thx

Feels like this is going to change with the rule-type-specific route stuff in a subsequent PR anyway, so feels like we should just leave it alone for now :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok sounds good!

Copy link
Contributor

@benakansara benakansara left a comment

Choose a reason for hiding this comment

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

AO changes LGTM.

@ymao1

This comment was marked as resolved.

@jonathan-buttner jonathan-buttner added the ci:cloud-deploy Create or update a Cloud deployment label Nov 15, 2022
@jonathan-buttner
Copy link
Contributor Author

When I run this PR with an empty ES (no rules) and go to Stack Management, I see this error:

with a network error for failing to resolve https://localhost:5601/internal/alerting/rule/undefined/_resolve. I did not see this on main.

Following up as we've continued this discussion offline. Christos and I tried to reproduce this and we weren't able to. Ying also checked on the cloud deployment and wasn't seeing it there. Seems like this is a race condition somewhere.

@jonathan-buttner jonathan-buttner enabled auto-merge (squash) November 15, 2022 20:58
@kibana-ci
Copy link
Collaborator

kibana-ci commented Nov 15, 2022

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
apm 1323 1324 +1
cases 511 512 +1
infra 1146 1147 +1
observability 431 432 +1
securitySolution 3294 3295 +1
synthetics 1076 1077 +1
timelines 191 192 +1
triggersActionsUi 461 462 +1
total +8

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/rule-data-utils 83 87 +4

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
triggersActionsUi 663.6KB 655.5KB -8.2KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
triggersActionsUi 104.0KB 108.1KB +4.1KB
Unknown metric groups

API count

id before after diff
@kbn/rule-data-utils 86 90 +4

async chunk count

id before after diff
triggersActionsUi 53 52 -1

ESLint disabled in files

id before after diff
osquery 1 2 +1

ESLint disabled line counts

id before after diff
enterpriseSearch 19 21 +2
fleet 59 65 +6
osquery 108 113 +5
securitySolution 441 447 +6
total +19

Total ESLint disabled count

id before after diff
enterpriseSearch 20 22 +2
fleet 67 73 +6
osquery 109 115 +6
securitySolution 518 524 +6
total +20

History

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

@jonathan-buttner jonathan-buttner merged commit 2180a8a into elastic:main Nov 15, 2022
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Nov 15, 2022
@jonathan-buttner jonathan-buttner deleted the rule-url-variable branch November 16, 2022 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting ci:cloud-deploy Create or update a Cloud deployment Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants