…ents tree (elastic#225650)

## Summary

Fixes elastic#211537

---

When opening an alert deeplink, the new page doesn't load the filters
for the alerts table correctly (see issue for more details).

This is the flow:
- The user opens a deeplink like this `/alerts/redirect/:alertId?params`
- The redirect page generates an appropriate URL, like `/alerts?params`
and redirects to it
- The browser should navigate to the alerts page and render a table
filtered by ID and time range, with an open flyout displaying the
details of the alert.

## The problem

This is apparently caused by the fact that the effect that syncs the URL
with the redux store for the alerts page gets executed before the
`<Redirect/>` to the alerts page, which is placed at the end of the
components tree.

Here's what happens:
- Browser navigates to the `/alerts/redirect/` URL
- Because of some logic up-tree, the application doesn't render the
Alerts page, skipping the `<Redirect />`
- In the meantime, the sync effect runs anyways because it's placed
before the mentioned logic
- The sync effect is not meant to sync on the `/alert/redirect` URL, as
it should sync after the `<Redirect />` has been executed
- On the following render, the `<Redirect />` get executed, but the sync
effect won't run again

## Solution

After discussing it in the issue, we reached the conclusion that moving
this redirect before the effect is the cleanest solution.
This way the `<Redirec />` runs before the effect, allowing the page to
load as intended

(cherry picked from commit 8023585)

…ents tree (elastic#225650)

## Summary

Fixes elastic#211537

---

When opening an alert deeplink, the new page doesn't load the filters
for the alerts table correctly (see issue for more details).

This is the flow:
- The user opens a deeplink like this `/alerts/redirect/:alertId?params`
- The redirect page generates an appropriate URL, like `/alerts?params`
and redirects to it
- The browser should navigate to the alerts page and render a table
filtered by ID and time range, with an open flyout displaying the
details of the alert.

## The problem

This is apparently caused by the fact that the effect that syncs the URL
with the redux store for the alerts page gets executed before the
`<Redirect/>` to the alerts page, which is placed at the end of the
components tree.

Here's what happens:
- Browser navigates to the `/alerts/redirect/` URL
- Because of some logic up-tree, the application doesn't render the
Alerts page, skipping the `<Redirect />`
- In the meantime, the sync effect runs anyways because it's placed
before the mentioned logic
- The sync effect is not meant to sync on the `/alert/redirect` URL, as
it should sync after the `<Redirect />` has been executed
- On the following render, the `<Redirect />` get executed, but the sync
effect won't run again

## Solution

After discussing it in the issue, we reached the conclusion that moving
this redirect before the effect is the cleanest solution.
This way the `<Redirec />` runs before the effect, allowing the page to
load as intended

(cherry picked from commit 8023585)

…ents tree (elastic#225650)

## Summary

Fixes elastic#211537

---

When opening an alert deeplink, the new page doesn't load the filters
for the alerts table correctly (see issue for more details).

This is the flow:
- The user opens a deeplink like this `/alerts/redirect/:alertId?params`
- The redirect page generates an appropriate URL, like `/alerts?params`
and redirects to it
- The browser should navigate to the alerts page and render a table
filtered by ID and time range, with an open flyout displaying the
details of the alert.

## The problem

This is apparently caused by the fact that the effect that syncs the URL
with the redux store for the alerts page gets executed before the
`<Redirect/>` to the alerts page, which is placed at the end of the
components tree.

Here's what happens:
- Browser navigates to the `/alerts/redirect/` URL
- Because of some logic up-tree, the application doesn't render the
Alerts page, skipping the `<Redirect />`
- In the meantime, the sync effect runs anyways because it's placed
before the mentioned logic
- The sync effect is not meant to sync on the `/alert/redirect` URL, as
it should sync after the `<Redirect />` has been executed
- On the following render, the `<Redirect />` get executed, but the sync
effect won't run again

## Solution

After discussing it in the issue, we reached the conclusion that moving
this redirect before the effect is the cleanest solution.
This way the `<Redirec />` runs before the effect, allowing the page to
load as intended

(cherry picked from commit 8023585)

…ents tree (elastic#225650)

## Summary

Fixes elastic#211537

---

When opening an alert deeplink, the new page doesn't load the filters
for the alerts table correctly (see issue for more details).

This is the flow:
- The user opens a deeplink like this `/alerts/redirect/:alertId?params`
- The redirect page generates an appropriate URL, like `/alerts?params`
and redirects to it
- The browser should navigate to the alerts page and render a table
filtered by ID and time range, with an open flyout displaying the
details of the alert.

## The problem

This is apparently caused by the fact that the effect that syncs the URL
with the redux store for the alerts page gets executed before the
`<Redirect/>` to the alerts page, which is placed at the end of the
components tree.

Here's what happens:
- Browser navigates to the `/alerts/redirect/` URL
- Because of some logic up-tree, the application doesn't render the
Alerts page, skipping the `<Redirect />`
- In the meantime, the sync effect runs anyways because it's placed
before the mentioned logic
- The sync effect is not meant to sync on the `/alert/redirect` URL, as
it should sync after the `<Redirect />` has been executed
- On the following render, the `<Redirect />` get executed, but the sync
effect won't run again

## Solution

After discussing it in the issue, we reached the conclusion that moving
this redirect before the effect is the cleanest solution.
This way the `<Redirec />` runs before the effect, allowing the page to
load as intended

(cherry picked from commit 8023585)

…components tree (#225650) (#225850)

# Backport

This will backport the following commits from `main` to `9.1`:
- [[Security Solution][Alerts] Move alerts redirect higher in the
components tree
(#225650)](#225650)

<!--- Backport version: 9.6.6 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Nicholas
Peretti","email":"nicholas.peretti@elastic.co"},"sourceCommit":{"committedDate":"2025-06-30T13:47:24Z","message":"[Security
Solution][Alerts] Move alerts redirect higher in the components tree
(#225650)\n\n## Summary\n\nFixes #211537 \n\n---\n\nWhen opening an
alert deeplink, the new page doesn't load the filters\nfor the alerts
table correctly (see issue for more details).\n\nThis is the flow:\n-
The user opens a deeplink like this
`/alerts/redirect/:alertId?params`\n- The redirect page generates an
appropriate URL, like `/alerts?params`\nand redirects to it\n- The
browser should navigate to the alerts page and render a table\nfiltered
by ID and time range, with an open flyout displaying the\ndetails of the
alert.\n\n## The problem\n\nThis is apparently caused by the fact that
the effect that syncs the URL\nwith the redux store for the alerts page
gets executed before the\n`<Redirect/>` to the alerts page, which is
placed at the end of the\ncomponents tree.\n\nHere's what happens:\n-
Browser navigates to the `/alerts/redirect/` URL\n- Because of some
logic up-tree, the application doesn't render the\nAlerts page, skipping
the `<Redirect />`\n- In the meantime, the sync effect runs anyways
because it's placed\nbefore the mentioned logic\n- The sync effect is
not meant to sync on the `/alert/redirect` URL, as\nit should sync after
the `<Redirect />` has been executed\n- On the following render, the
`<Redirect />` get executed, but the sync\neffect won't run again\n\n##
Solution\n\nAfter discussing it in the issue, we reached the conclusion
that moving\nthis redirect before the effect is the cleanest
solution.\nThis way the `<Redirec />` runs before the effect, allowing
the page to\nload as
intended","sha":"8023585c6b4aa071848e0c17eb72a463ecadef6a","branchLabelMapping":{"^v9.2.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Threat
Hunting","backport:version","v9.1.0","v8.19.0","v9.2.0"],"title":"[Security
Solution][Alerts] Move alerts redirect higher in the components
tree","number":225650,"url":"https://github.com/elastic/kibana/pull/225650","mergeCommit":{"message":"[Security
Solution][Alerts] Move alerts redirect higher in the components tree
(#225650)\n\n## Summary\n\nFixes #211537 \n\n---\n\nWhen opening an
alert deeplink, the new page doesn't load the filters\nfor the alerts
table correctly (see issue for more details).\n\nThis is the flow:\n-
The user opens a deeplink like this
`/alerts/redirect/:alertId?params`\n- The redirect page generates an
appropriate URL, like `/alerts?params`\nand redirects to it\n- The
browser should navigate to the alerts page and render a table\nfiltered
by ID and time range, with an open flyout displaying the\ndetails of the
alert.\n\n## The problem\n\nThis is apparently caused by the fact that
the effect that syncs the URL\nwith the redux store for the alerts page
gets executed before the\n`<Redirect/>` to the alerts page, which is
placed at the end of the\ncomponents tree.\n\nHere's what happens:\n-
Browser navigates to the `/alerts/redirect/` URL\n- Because of some
logic up-tree, the application doesn't render the\nAlerts page, skipping
the `<Redirect />`\n- In the meantime, the sync effect runs anyways
because it's placed\nbefore the mentioned logic\n- The sync effect is
not meant to sync on the `/alert/redirect` URL, as\nit should sync after
the `<Redirect />` has been executed\n- On the following render, the
`<Redirect />` get executed, but the sync\neffect won't run again\n\n##
Solution\n\nAfter discussing it in the issue, we reached the conclusion
that moving\nthis redirect before the effect is the cleanest
solution.\nThis way the `<Redirec />` runs before the effect, allowing
the page to\nload as
intended","sha":"8023585c6b4aa071848e0c17eb72a463ecadef6a"}},"sourceBranch":"main","suggestedTargetBranches":["9.1","8.19"],"targetPullRequestStates":[{"branch":"9.1","label":"v9.1.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.2.0","branchLabelMappingKey":"^v9.2.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/225650","number":225650,"mergeCommit":{"message":"[Security
Solution][Alerts] Move alerts redirect higher in the components tree
(#225650)\n\n## Summary\n\nFixes #211537 \n\n---\n\nWhen opening an
alert deeplink, the new page doesn't load the filters\nfor the alerts
table correctly (see issue for more details).\n\nThis is the flow:\n-
The user opens a deeplink like this
`/alerts/redirect/:alertId?params`\n- The redirect page generates an
appropriate URL, like `/alerts?params`\nand redirects to it\n- The
browser should navigate to the alerts page and render a table\nfiltered
by ID and time range, with an open flyout displaying the\ndetails of the
alert.\n\n## The problem\n\nThis is apparently caused by the fact that
the effect that syncs the URL\nwith the redux store for the alerts page
gets executed before the\n`<Redirect/>` to the alerts page, which is
placed at the end of the\ncomponents tree.\n\nHere's what happens:\n-
Browser navigates to the `/alerts/redirect/` URL\n- Because of some
logic up-tree, the application doesn't render the\nAlerts page, skipping
the `<Redirect />`\n- In the meantime, the sync effect runs anyways
because it's placed\nbefore the mentioned logic\n- The sync effect is
not meant to sync on the `/alert/redirect` URL, as\nit should sync after
the `<Redirect />` has been executed\n- On the following render, the
`<Redirect />` get executed, but the sync\neffect won't run again\n\n##
Solution\n\nAfter discussing it in the issue, we reached the conclusion
that moving\nthis redirect before the effect is the cleanest
solution.\nThis way the `<Redirec />` runs before the effect, allowing
the page to\nload as
intended","sha":"8023585c6b4aa071848e0c17eb72a463ecadef6a"}}]}]
BACKPORT-->

Co-authored-by: Nicholas Peretti <nicholas.peretti@elastic.co>

… components tree (#225650) (#225849)

# Backport

This will backport the following commits from `main` to `8.19`:
- [[Security Solution][Alerts] Move alerts redirect higher in the
components tree
(#225650)](#225650)

<!--- Backport version: 9.6.6 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Nicholas
Peretti","email":"nicholas.peretti@elastic.co"},"sourceCommit":{"committedDate":"2025-06-30T13:47:24Z","message":"[Security
Solution][Alerts] Move alerts redirect higher in the components tree
(#225650)\n\n## Summary\n\nFixes #211537 \n\n---\n\nWhen opening an
alert deeplink, the new page doesn't load the filters\nfor the alerts
table correctly (see issue for more details).\n\nThis is the flow:\n-
The user opens a deeplink like this
`/alerts/redirect/:alertId?params`\n- The redirect page generates an
appropriate URL, like `/alerts?params`\nand redirects to it\n- The
browser should navigate to the alerts page and render a table\nfiltered
by ID and time range, with an open flyout displaying the\ndetails of the
alert.\n\n## The problem\n\nThis is apparently caused by the fact that
the effect that syncs the URL\nwith the redux store for the alerts page
gets executed before the\n`<Redirect/>` to the alerts page, which is
placed at the end of the\ncomponents tree.\n\nHere's what happens:\n-
Browser navigates to the `/alerts/redirect/` URL\n- Because of some
logic up-tree, the application doesn't render the\nAlerts page, skipping
the `<Redirect />`\n- In the meantime, the sync effect runs anyways
because it's placed\nbefore the mentioned logic\n- The sync effect is
not meant to sync on the `/alert/redirect` URL, as\nit should sync after
the `<Redirect />` has been executed\n- On the following render, the
`<Redirect />` get executed, but the sync\neffect won't run again\n\n##
Solution\n\nAfter discussing it in the issue, we reached the conclusion
that moving\nthis redirect before the effect is the cleanest
solution.\nThis way the `<Redirec />` runs before the effect, allowing
the page to\nload as
intended","sha":"8023585c6b4aa071848e0c17eb72a463ecadef6a","branchLabelMapping":{"^v9.2.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Threat
Hunting","backport:version","v9.1.0","v8.19.0","v9.2.0"],"title":"[Security
Solution][Alerts] Move alerts redirect higher in the components
tree","number":225650,"url":"https://github.com/elastic/kibana/pull/225650","mergeCommit":{"message":"[Security
Solution][Alerts] Move alerts redirect higher in the components tree
(#225650)\n\n## Summary\n\nFixes #211537 \n\n---\n\nWhen opening an
alert deeplink, the new page doesn't load the filters\nfor the alerts
table correctly (see issue for more details).\n\nThis is the flow:\n-
The user opens a deeplink like this
`/alerts/redirect/:alertId?params`\n- The redirect page generates an
appropriate URL, like `/alerts?params`\nand redirects to it\n- The
browser should navigate to the alerts page and render a table\nfiltered
by ID and time range, with an open flyout displaying the\ndetails of the
alert.\n\n## The problem\n\nThis is apparently caused by the fact that
the effect that syncs the URL\nwith the redux store for the alerts page
gets executed before the\n`<Redirect/>` to the alerts page, which is
placed at the end of the\ncomponents tree.\n\nHere's what happens:\n-
Browser navigates to the `/alerts/redirect/` URL\n- Because of some
logic up-tree, the application doesn't render the\nAlerts page, skipping
the `<Redirect />`\n- In the meantime, the sync effect runs anyways
because it's placed\nbefore the mentioned logic\n- The sync effect is
not meant to sync on the `/alert/redirect` URL, as\nit should sync after
the `<Redirect />` has been executed\n- On the following render, the
`<Redirect />` get executed, but the sync\neffect won't run again\n\n##
Solution\n\nAfter discussing it in the issue, we reached the conclusion
that moving\nthis redirect before the effect is the cleanest
solution.\nThis way the `<Redirec />` runs before the effect, allowing
the page to\nload as
intended","sha":"8023585c6b4aa071848e0c17eb72a463ecadef6a"}},"sourceBranch":"main","suggestedTargetBranches":["9.1","8.19"],"targetPullRequestStates":[{"branch":"9.1","label":"v9.1.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.2.0","branchLabelMappingKey":"^v9.2.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/225650","number":225650,"mergeCommit":{"message":"[Security
Solution][Alerts] Move alerts redirect higher in the components tree
(#225650)\n\n## Summary\n\nFixes #211537 \n\n---\n\nWhen opening an
alert deeplink, the new page doesn't load the filters\nfor the alerts
table correctly (see issue for more details).\n\nThis is the flow:\n-
The user opens a deeplink like this
`/alerts/redirect/:alertId?params`\n- The redirect page generates an
appropriate URL, like `/alerts?params`\nand redirects to it\n- The
browser should navigate to the alerts page and render a table\nfiltered
by ID and time range, with an open flyout displaying the\ndetails of the
alert.\n\n## The problem\n\nThis is apparently caused by the fact that
the effect that syncs the URL\nwith the redux store for the alerts page
gets executed before the\n`<Redirect/>` to the alerts page, which is
placed at the end of the\ncomponents tree.\n\nHere's what happens:\n-
Browser navigates to the `/alerts/redirect/` URL\n- Because of some
logic up-tree, the application doesn't render the\nAlerts page, skipping
the `<Redirect />`\n- In the meantime, the sync effect runs anyways
because it's placed\nbefore the mentioned logic\n- The sync effect is
not meant to sync on the `/alert/redirect` URL, as\nit should sync after
the `<Redirect />` has been executed\n- On the following render, the
`<Redirect />` get executed, but the sync\neffect won't run again\n\n##
Solution\n\nAfter discussing it in the issue, we reached the conclusion
that moving\nthis redirect before the effect is the cleanest
solution.\nThis way the `<Redirec />` runs before the effect, allowing
the page to\nload as
intended","sha":"8023585c6b4aa071848e0c17eb72a463ecadef6a"}}]}]
BACKPORT-->

Co-authored-by: Nicholas Peretti <nicholas.peretti@elastic.co>
Co-authored-by: Philippe Oberti <philippe.oberti@elastic.co>