[Security Solution][Detection Engine] changes codeowners for rule create/edit form components

[vitaliidm]

Summary

• addresses [Security Solution][Alerts] change ownership for components used in rule create/edit #145420
• moves almost all of the components from /x-pack/plugins/security_solution/public/detections/components/rules to
  • x-pack/plugins/security_solution/public/detection_engine/rule_creation_ui/components , rule_creation_ui
    components that used only in rule creation are placed here
  • x-pack/plugins/security_solution/public/detection_engine/rule_creation/components , rule_creation
    components that used also in another areas(details, or rule tables), placed here
  • some of the basic components, like technical_preview_badge or severity_badge moved to common area: x-pack/plugins/security_solution/public/common/components

The rest of the components, used by rule-management team only, left /x-pack/plugins/security_solution/public/detections/components/rules.

rule_creation and rule_creation_ui folders owned by detection-engine team

Next steps?

Since the main purpose of this PR to change codeownership of components, there are still quite a few places where different types are imported from rule_creation_ui folder. For example. Type FieldValueQueryBar is imported in timeline component. With this refactoring, it becomes much easier to identify such imports and refactor it further in future

[vitaliidm]

/ci

[vitaliidm]

/ci

[vitaliidm]

/ci

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[stephmilovic]

Code changes LGTM for Explore team!

[yctercero]

Thanks so much for getting to this - I think it's super helpful. I don't want to block as this touches a ton of files and I think it's a good move forward. I am wondering if we could reduce a bit of the complexity by merging some of these folders so the structure might be something like:

detections_response
  --> rule_creation
        --> components
               --> common
        --> containers
         --> logic
        --> pages (what you have as rule_creation_ui right now)
  --> rule_details
        --> components
               --> common
        --> containers
         --> logic
        --> pages (what you have as rule_details_ui right now)
  --> rule_edit
        --> components
               --> common
        --> containers
         --> logic
        --> pages 

[vitaliidm]

@yctercero , thanks for feedback and proposal

Changes in PR are based on adopted earlier folder structure(#142950, a lot more in description with diagrams) and follow existing approach.
If we would like to change it, I propose to start discussion outside of this PR and agree on a new folder structure, if we find it more helpful. As my aim here was mainly to assign correct ownership and follow existing guidelines, I don't want to go outside of its scope and introduce major code structuring changes

[yctercero]

@yctercero , thanks for feedback and proposal

Changes in PR are based on adopted earlier folder structure(#142950, a lot more in description with diagrams) and follow existing approach. If we would like to change it, I propose to start discussion outside of this PR and agree on a new folder structure, if we find it more helpful. As my aim here was mainly to assign correct ownership and follow existing guidelines, I don't want to go outside of its scope and introduce major code structuring changes

Makes sense! I don't think further restructure is a priority and like you mentioned the goal is to update ownership and this does just that! Thanks, I'll LGTM.

[banderror]

Rule Management changes LGTM 👍

Components moved and components left in public/detections/components/rules make sense. I left a couple of minor questions.

Great refactoring, thank you @vitaliidm!

[banderror]

I think MITRE components and model should be either under public/detection_engine/rule_management or its own generic subdomain public/detection_engine/mitre. Maybe except for the code that implements the form inputs for MITRE mappings, not sure.

Updating MITRE mappings is on the Rule Management team, specifically, @dplumlee used to do that work. We also own the MITRE Coverage Overview page.

I'd be ok merging this as is and taking a closer look at the public/detection_engine/rule_creation_ui/components/mitre folder later.

[banderror]

Nit: Just curious why components for the About, Define, and Schedule sections are under rule_creation_ui, but the one for the Actions section is under rule_creation?

[vitaliidm]

actions component is used within details section: https://github.com/elastic/kibana/pull/173906/files#diff-910140c9d6034d2b98eab04e82f22ac18451fe485e1951997ad22004b8920f56R66

I also notices, Details component used there too, so moved it as well to rule_creation. The rest are still in rule_creation_ui

[banderror]

@yctercero @vitaliidm regarding #173906 (review):

The complexity is objectively there, but it has a reason. Our pages are complex and contain pieces from different subdomains. For instance, the Rule Details page contains: the rule details functionality itself, rule management actions, some ML jobs UI, rule monitoring UI, alerts table, exceptions. We can't keep all that code under a single detection_engine/rule_details folder - because some of it is used on other pages too. If we'd keep reusable code in folders like detection_engine/rule_details, we'd end up having bi-directional and circular dependencies between folders and unclear rules where to keep what code.

That's why we need at least two layers of code on the FE side: a layer of subdomains and a layer for pages. In #142950 we proposed that pages should live in "UI subdomains". Maybe that's what confuses people and we just need to tweak the folder structure a bit to remove this confusion. Something like that:

• detection_engine
  • core or subdomains
    • rule_creation
    • rule_management
    • etc
  • pages
    • rule_creation
    • rule_editing
    • rule_details
    • rule_management
    • etc

++ for "If we would like to change it, I propose to start discussion outside of this PR and agree on a new folder structure"

[yctercero]

@yctercero @vitaliidm regarding #173906 (review):

The complexity is objectively there, but it has a reason. Our pages are complex and contain pieces from different subdomains. For instance, the Rule Details page contains: the rule details functionality itself, rule management actions, some ML jobs UI, rule monitoring UI, alerts table, exceptions. We can't keep all that code under a single detection_engine/rule_details folder - because some of it is used on other pages too. If we'd keep reusable code in folders like detection_engine/rule_details, we'd end up having bi-directional and circular dependencies between folders and unclear rules where to keep what code.

That's why we need at least two layers of code on the FE side: a layer of subdomains and a layer for pages. In #142950 we proposed that pages should live in "UI subdomains". Maybe that's what confuses people and we just need to tweak the folder structure a bit to remove this confusion. Something like that:

• detection_engine

  • core or subdomains

    • rule_creation
    • rule_management
    • etc

  • pages

    • rule_creation
    • rule_editing
    • rule_details
    • rule_management
    • etc

++ for "If we would like to change it, I propose to start discussion outside of this PR and agree on a new folder structure"

Thanks for the background on it. I do like that suggested structure. Though I think it's not a priority right now. Maybe if we get feedback from devs that it's confusing we can re-examine.

[tomsonpl]

Defend Workflows changes LGTM 👍

[janmonschke]

THI changes lgtm 👍

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: fedb929

Failed CI Steps

• FTR Configs #78

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	4863	4864	+1

Async chunks

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

id	before	after	diff
securitySolution	11.4MB	11.4MB	-281.0B

History

• 💔 Build #186317 failed c982c60
• 💚 Build #186174 succeeded e7c2fef
• 💚 Build #185704 succeeded 1256b8a
• 💛 Build #185345 was flaky 82d7e12
• 💛 Build #184955 was flaky e1af11d

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

cc @vitaliidm