fix: preserve condition values when updating user settings

[abdimo101]

Description

This PR fixes an issue where condition values are lost when navigating away from and back to the dashboard without refreshing the page.

Motivation

Background on use case, changes needed

Fixes:

Please provide a list of the fixes implemented in this PR

• Items added

Changes:

Please provide a list of the changes implemented by this PR

• changes made

Tests included

• Included for each change/fix?
• Passing? (Merge will not be approved unless this is checked)

Documentation

• swagger documentation updated [required]
• official documentation updated [nice-to-have]

official documentation info

If you have updated the official documentation, please provide PR # and URL of the pages where the updates are included

Backend version

• Does it require a specific version of the backend
• which version of the backend is required:

Summary by Sourcery

Preserve dataset filter conditions in user settings so condition values persist when navigating away and back to the datasets view.

Bug Fixes:

• Ensure user settings reducer persists condition configurations, including conditions, when updating settings.
• Stop clearing temporary condition values when changing a condition operator so entered values are retained across navigation.

Tests:

• Add an end-to-end test verifying that scientific condition values remain intact after navigating from the datasets list to a dataset detail view and back.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In the new Cypress test, consider relying more consistently on stable data-cy selectors instead of structural selectors like .condition-panel, mat-select, and mat-option, which are brittle to DOM or component-library changes.
• The userSettings as any cast in the reducer makes it easy to miss shape changes like the new conditions field; introducing a typed interface for userSettings (including conditions) would make these updates safer and easier to maintain.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the new Cypress test, consider relying more consistently on stable `data-cy` selectors instead of structural selectors like `.condition-panel`, `mat-select`, and `mat-option`, which are brittle to DOM or component-library changes.
- The `userSettings as any` cast in the reducer makes it easy to miss shape changes like the new `conditions` field; introducing a typed interface for `userSettings` (including `conditions`) would make these updates safer and easier to maintain.

## Individual Comments

### Comment 1
<location> `cypress/e2e/datasets/datasets-general.cy.js:716-722` </location>
<code_context>
+
+      cy.get('[data-cy="edit-general-information"]').should("exist");
+
+      cy.go('back');
+
+      cy.get(".condition-panel")
+      .first()
+      .find("mat-panel-title")
+      .should("contain", ">")
+      .and("contain", "19");
+    });
+  })
</code_context>

<issue_to_address>
**suggestion (testing):** Selectors in the new test are fairly generic and may be brittle over time.

The assertions after `cy.go('back')` depend on generic selectors like `.condition-panel` and `mat-panel-title` plus content matches (`>` and `19`), which ties the test to presentation details and may break on minor layout/label changes. Where possible, prefer dedicated hooks (e.g. `data-cy` attributes) for the condition panels and operator/value fields so the test stays stable while still verifying the persisted condition state.

Suggested implementation:

```javascript
      cy.go('back');

      cy.get('[data-cy="condition-panel"]')
        .first()
        .within(() => {
          cy.get('[data-cy="condition-operator"]').should("contain", ">");
          cy.get('[data-cy="condition-value"]').should("contain", "19");
        });

```

To make this test pass and keep it robust, you’ll need to:
1. Add `data-cy="condition-panel"` to the element that currently has the `.condition-panel` class in the UI template.
2. Add `data-cy="condition-operator"` to the element within the condition panel that displays the comparison operator (currently the part that ends up in `mat-panel-title`).
3. Add `data-cy="condition-value"` to the element within the condition panel that displays the value (`19` in this test).
4. If the operator/value are rendered differently (e.g., inside chips or separate spans), adjust the specific `data-cy` hooks accordingly, while keeping the Cypress selectors aligned with those hooks.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (testing): Selectors in the new test are fairly generic and may be brittle over time.

The assertions after cy.go('back') depend on generic selectors like .condition-panel and mat-panel-title plus content matches (> and 19), which ties the test to presentation details and may break on minor layout/label changes. Where possible, prefer dedicated hooks (e.g. data-cy attributes) for the condition panels and operator/value fields so the test stays stable while still verifying the persisted condition state.

Suggested implementation:

      cy.go('back');

      cy.get('[data-cy="condition-panel"]')
        .first()
        .within(() => {
          cy.get('[data-cy="condition-operator"]').should("contain", ">");
          cy.get('[data-cy="condition-value"]').should("contain", "19");
        });

To make this test pass and keep it robust, you’ll need to:

1. Add data-cy="condition-panel" to the element that currently has the .condition-panel class in the UI template.
2. Add data-cy="condition-operator" to the element within the condition panel that displays the comparison operator (currently the part that ends up in mat-panel-title).
3. Add data-cy="condition-value" to the element within the condition panel that displays the value (19 in this test).
4. If the operator/value are rendered differently (e.g., inside chips or separate spans), adjust the specific data-cy hooks accordingly, while keeping the Cypress selectors aligned with those hooks.