Skip to content

refactor: improve filters and conditions section in dataset dashboard #1927

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

Open
wants to merge 22 commits into
base: master
Choose a base branch
from

Conversation

abdimo101
Copy link
Contributor

@abdimo101 abdimo101 commented Jul 7, 2025

Description

  • Moved the condition management from settings dialog to main filter component for better UX.
  • Replaced dialog-based condition editing with Material expansion panels.
  • Updated filter UI styling and layout.

conditions-after-part1
conditions-after-part2

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

Refactor the dataset dashboard’s filter section to manage scientific conditions directly within the main panel using Material expansion panels, refresh UI styling and layout, clean up old dialog code, and update tests accordingly

Enhancements:

  • Move scientific condition management out of the settings dialog into the main filter panel
  • Replace dialog-based editing of conditions with inline Material expansion panels
  • Update filter header to include a dedicated settings button and rename to “Filters”
  • Improve condition display by formatting relation symbols and units

Build:

  • Add MatExpansionModule, MatSelectModule, MatFormFieldModule, and MatButtonModule imports for condition controls

Tests:

  • Update Cypress tests to interact with the new inline condition panels
  • Adjust component unit tests after removing dialog-based condition logic

Chores:

  • Remove obsolete condition configuration code from the settings dialog component

@abdimo101 abdimo101 requested a review from Junjiequan July 7, 2025 10:17
Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

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

Hey @abdimo101 - I've reviewed your changes and they look great!

Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `src/app/datasets/datasets-filter/datasets-filter.component.ts:212` </location>
<code_context>
+    return `${condition.lhs}-${index}`;
+  }
+
+  getConditionDisplayText(condition: any): string {
+    if (!condition.lhs || !condition.rhs) return "Configure condition...";
+
+    let relationSymbol = "";
+    switch (condition.relation) {
+      case "EQUAL_TO_NUMERIC":
+      case "EQUAL_TO_STRING":
+        relationSymbol = "=";
+        break;
+      case "LESS_THAN":
+        relationSymbol = "<";
+        break;
+      case "GREATER_THAN":
+        relationSymbol = ">";
+        break;
+      default:
+        relationSymbol = "";
+    }
+
+    const rhsValue =
+      condition.relation === "EQUAL_TO_STRING"
+        ? `"${condition.rhs}"`
+        : condition.rhs;
+
+    const unit = condition.unit ? ` ${condition.unit}` : "";
+    return `${relationSymbol} ${rhsValue}${unit}`;
+  }
+
</code_context>

<issue_to_address>
getConditionDisplayText may not handle all possible relation types.

If new relation types are added, they will default to an empty symbol, which may be unclear. Please handle all relation types explicitly or provide a clearer fallback.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
  getConditionDisplayText(condition: any): string {
    if (!condition.lhs || !condition.rhs) return "Configure condition...";

    let relationSymbol = "";
    switch (condition.relation) {
      case "EQUAL_TO_NUMERIC":
      case "EQUAL_TO_STRING":
        relationSymbol = "=";
        break;
      case "LESS_THAN":
        relationSymbol = "<";
        break;
      case "GREATER_THAN":
        relationSymbol = ">";
        break;
      default:
        relationSymbol = "";
    }

    const rhsValue =
      condition.relation === "EQUAL_TO_STRING"
        ? `"${condition.rhs}"`
        : condition.rhs;

    const unit = condition.unit ? ` ${condition.unit}` : "";
    return `${relationSymbol} ${rhsValue}${unit}`;
  }
=======
  getConditionDisplayText(condition: any): string {
    if (!condition.lhs || !condition.rhs) return "Configure condition...";

    let relationSymbol: string;
    switch (condition.relation) {
      case "EQUAL_TO_NUMERIC":
      case "EQUAL_TO_STRING":
        relationSymbol = "=";
        break;
      case "LESS_THAN":
        relationSymbol = "<";
        break;
      case "GREATER_THAN":
        relationSymbol = ">";
        break;
      case "NOT_EQUAL_TO_NUMERIC":
      case "NOT_EQUAL_TO_STRING":
        relationSymbol = "≠";
        break;
      case "LESS_THAN_OR_EQUAL":
        relationSymbol = "≤";
        break;
      case "GREATER_THAN_OR_EQUAL":
        relationSymbol = "≥";
        break;
      // Add more known relation types here as needed
      default:
        // Fallback: show the relation name in a readable way
        relationSymbol = condition.relation
          ? `[${condition.relation.replace(/_/g, " ").toLowerCase()}]`
          : "?";
    }

    const rhsValue =
      condition.relation === "EQUAL_TO_STRING" || condition.relation === "NOT_EQUAL_TO_STRING"
        ? `"${condition.rhs}"`
        : condition.rhs;

    const unit = condition.unit ? ` ${condition.unit}` : "";
    return `${relationSymbol} ${rhsValue}${unit}`;
  }
>>>>>>> REPLACE

</suggested_fix>

### Comment 2
<location> `src/app/datasets/datasets-filter/datasets-filter.component.ts:379` </location>
<code_context>
+    this.updateConditionInStore(updatedConditions);
+  }
+
+  updateConditionOperator(index: number, newOperator: string) {
+    this.updateCondition(index, {
+      relation: newOperator as any,
+      unit: newOperator === "EQUAL_TO_STRING" ? "" : undefined,
</code_context>

<issue_to_address>
Setting unit to empty string for EQUAL_TO_STRING may cause inconsistencies.

Storing unit as an empty string may differ from omitting it or setting it to undefined. Normalize the unit field to undefined or remove it when not needed.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
  updateConditionOperator(index: number, newOperator: string) {
    this.updateCondition(index, {
      relation: newOperator as any,
      unit: newOperator === "EQUAL_TO_STRING" ? "" : undefined,
    });
  }
=======
  updateConditionOperator(index: number, newOperator: string) {
    const update: any = { relation: newOperator as any };
    if (newOperator !== "EQUAL_TO_STRING") {
      update.unit = undefined;
    }
    this.updateCondition(index, update);
  }
>>>>>>> REPLACE

</suggested_fix>

### Comment 3
<location> `src/app/datasets/datasets-filter/datasets-filter.component.ts:386` </location>
<code_context>
+    });
+  }
+
+  updateConditionValue(index: number, event: Event) {
+    const newValue = (event.target as HTMLInputElement).value;
+    this.updateCondition(index, { rhs: newValue });
+  }
+
</code_context>

<issue_to_address>
No type conversion is performed for numeric values in updateConditionValue.

If numeric conditions require a number, convert the input value accordingly before updating.

Suggested implementation:

```typescript
  updateConditionValue(index: number, event: Event) {
    const inputValue = (event.target as HTMLInputElement).value;
    // Assuming you have a conditions array and each condition has a 'type' property
    const condition = this.conditions[index];
    let newValue: any = inputValue;
    if (condition && condition.type === 'number') {
      const parsed = Number(inputValue);
      newValue = isNaN(parsed) ? inputValue : parsed;
    }
    this.updateCondition(index, { rhs: newValue });
  }

```

- If your condition type property is named something other than `type`, or if you determine numeric conditions differently, adjust the check accordingly.
- Make sure `this.conditions` is accessible in this context. If not, use the appropriate way to access the condition metadata for the given index.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +386 to +388
updateConditionValue(index: number, event: Event) {
const newValue = (event.target as HTMLInputElement).value;
this.updateCondition(index, { rhs: newValue });
Copy link

Choose a reason for hiding this comment

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

suggestion: No type conversion is performed for numeric values in updateConditionValue.

If numeric conditions require a number, convert the input value accordingly before updating.

Suggested implementation:

  updateConditionValue(index: number, event: Event) {
    const inputValue = (event.target as HTMLInputElement).value;
    // Assuming you have a conditions array and each condition has a 'type' property
    const condition = this.conditions[index];
    let newValue: any = inputValue;
    if (condition && condition.type === 'number') {
      const parsed = Number(inputValue);
      newValue = isNaN(parsed) ? inputValue : parsed;
    }
    this.updateCondition(index, { rhs: newValue });
  }
  • If your condition type property is named something other than type, or if you determine numeric conditions differently, adjust the check accordingly.
  • Make sure this.conditions is accessible in this context. If not, use the appropriate way to access the condition metadata for the given index.

@Junjiequan Junjiequan force-pushed the datasets-filter-conditions branch from 5206918 to 390fa21 Compare July 8, 2025 07:50
Copy link
Member

@Junjiequan Junjiequan left a comment

Choose a reason for hiding this comment

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

It looks good to me .
just few comments.

return `${condition.lhs}-${index}`;
}

getConditionDisplayText(condition: any): string {
Copy link
Member

Choose a reason for hiding this comment

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

condition needs to be typed


updateConditionOperator(index: number, newOperator: string) {
this.updateCondition(index, {
relation: newOperator as any,
Copy link
Member

Choose a reason for hiding this comment

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

why as any here? arent relations fixed values

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was a quick fix for a type error, but it's working without it now so it's no longer necessary

@Junjiequan
Copy link
Member

Can you also include a test that checks pre-configured scientific metadata filter applies automatically on startup.
The condition fields are conifugred in the defaultDatasetsListSettings.condition from frontend.config.json file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants