[Security Solution] Persistent Rules table state

[banderror]

Related to: #126085, #126086

Summary

Currently, when the user refreshes the Rule Management page or navigates to another page, the state of the Rules table gets lost. When the user returns to the Rule Management page, they need to recover their filters, sorting, pagination, etc from scratch.

We want to:

1. Make the Rules table state persistent across SPA navigation, page refreshes and browser tabs.
2. Allow users to share deep links (links containing the state) to the table.

What do we mean by the Rules table state exactly:

• Current tab: Rules or Rule Monitoring
• Current mode: technical preview on/off
• Current filters: search bar, tags, elastic vs custom
• Current sorting: field and direction
• Current pagination: page size, page number (page number should persist only in the url)
• Current selection of rules: specific ids OR "all matching the current filter" (OR maybe also "all on the page")

Acceptance Criteria

GIVEN the user is on the Rule Management page and has some initial Rules table state (according to the definition above):

1. User should be able to navigate to the Details page by clicking on a rule name, click "Rules" to go back to the Management page, and find the table in the initial state.
2. User should be able to navigate inside the Security app, go back to the Rule Management page, and find the table in the initial state.
3. User should be able to navigate outside of the Security app, go back to the Rule Management page, and find the table in the initial state.
4. User should be able to refresh the page and find the table in the initial state.
5. User should be able to close the browser, reopen it, and find the table in the initial state.
6. User should be able to copy-paste the URL of the page to a different browser and find the table in the initial state.

Technical details

The suggestion is to make the table state persistent in two places:

1. The local storage. This would enable SPA navigation across the app + persistence between page refreshes and browser sessions.
2. The URL. This would allow users to share deep links to the table. Implement this on top of this prior art: [Security Solution] Improve url state management #134210.

Some thoughts:

• When the page is being loaded, during the process of recovering the table state, the state in the URL should take precedence over the state in local storage.
• When reading from the URL and (especially!) the local storage, we need the code to be resilient:
  • What if the local storage is not available, the quota is exceeded, etc. We'll need appropriate error handling for all those edge cases. Would be great if this has already been done in Kibana core or a package.
  • What if the persisted state is legacy/out-of-date (we refactored the table state, removed or added new state fields, etc). We will need the state to be versioned and some code for applying migrations to the old state. Example: timeline / data table state migrations.
  • What if the user copy-pasted not the whole link by mistake which broke the state in the URL.
  • Any other edge cases that we should consider and handle.

Todo

• Most of the implementation and basic test coverage (PR)
• Persistence of the selected tab as a path segment in the URL (PR, PR, PR)
• Removing the "< Rules" back button from the Rule Details page (PR)
• Test plan fully covering the business logic of this feature: Persistent Rules Table State
• Comprehensive test coverage matching scenarios from the test plan and covering edge cases (PR)

[elasticmachine]

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

[elasticmachine]

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

[maximpn]

The task has been discussed with @banderror, @xcrzx and the other team members and based on the discussion the following decisions have been made

• use sessionStorage for state persistence as it allows to use multiple browser tabs without interference and doesn't keep the state too long so users aren't confused but but the last selected filters after visiting the page in a month or so
• split the rules table and rules monitoring tables into two pages with separate path segments as it is a natural behaviour and allows to persist the selected tab in the url as a path segment
• rules table and rules monitoring tables may have different filters in the future (there are some unique columns for each of the table at the moment) so two different states should be persisted
• nav back link < Rules on the rule details page should be removed as it may confuse users clicking on a rule at the rules monitoring page so users expect returning back to the rules monitoring table. Besides that link there are breadcrumbs which allow to return back and back browser navigation button
• prepare a test plan for the feature

[gavinwye]

Thanks for the summary @maximpn

After the call yesterday I sketched up what we agreed (it's a bit scrappy) but aligns with what you've said here I think.

[banderror]

Implemented in the following PRs:

• [Security Solution] Persistent rules table state #145111
• [Security Solution] Persist rules table tab as a path segment #147471
• [Security Solution] Remove nav back to rules link #147357
• [Security Solution] Global query string functionality improvements #147218
• [Security Solution] Remove unused CSS selectors in function tests #148154
• [Security Solution] Cover persistent rules table state by e2e tests #149638