Enhance catalogue items table filtering

[asuresh-code]

Description

Enter a description of the changes here

Testing instructions

Add a set up instructions describing how the reviewer should test the code

• Review code
• Check Actions build
• Review changes to test coverage
• {more steps here}

Agile board tracking

Closes #1040

[codecov]

Codecov Report

Attention: Patch coverage is 98.75000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 99.18%. Comparing base (e32be58) to head (085c4a5).

Files with missing lines	Patch %	Lines
.../catalogue/items/catalogueItemsTable.component.tsx	98.51%	2 Missing ⚠️

Additional details and impacted files

@@                               Coverage Diff                               @@
##           feature/enhance-items-table-filtering-#1041    #1101      +/-   ##
===============================================================================
+ Coverage                                        99.16%   99.18%   +0.01%     
===============================================================================
  Files                                               81       81              
  Lines                                            16889    16933      +44     
  Branches                                          2843     2828      -15     
===============================================================================
+ Hits                                             16748    16795      +47     
+ Misses                                             137      134       -3     
  Partials                                             4        4              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joshuadkitenge]

remove ItemPropertyFiltersTypes as mentioned in the previous

[asuresh-code]

remove ItemPropertyFiltersTypes as mentioned in the previous

Currently there's a custom type for COLUMN_FILTER_VARIANTS, but there isn't one for COLUMN_FILTER_FUNCTIONS or COLUMN_FILTER_MODE_OPTIONS. Their implementation in the properties column (and general usage in other columns) are basically the same, so I think it makes sense for either all or none of them to have a custom type, instead of just COLUMN_FILTER_VARIANTS?

        filterVariant:
          COLUMN_FILTER_VARIANTS[
            property.type as 'string' | 'boolean' | 'number' | 'null'
          ],
        filterFn:
          COLUMN_FILTER_FUNCTIONS[
            property.type as 'string' | 'boolean' | 'number' | 'null'
          ],
        columnFilterModeOptions: [
          ...COLUMN_FILTER_MODE_OPTIONS[
            property.type as 'string' | 'boolean' | 'number' | 'null'
          ],
          ...(property.mandatory ? [] : OPTIONAL_FILTER_MODE_OPTIONS),
        ],

[joshuadkitenge]

remove ItemPropertyFiltersTypes as mentioned in the previous

Currently there's a custom type for COLUMN_FILTER_VARIANTS, but there isn't one for COLUMN_FILTER_FUNCTIONS or COLUMN_FILTER_MODE_OPTIONS. Their implementation in the properties column (and general usage in other columns) are basically the same, so I think it makes sense for either all or none of them to have a custom type, instead of just COLUMN_FILTER_VARIANTS?

        filterVariant:
          COLUMN_FILTER_VARIANTS[
            property.type as 'string' | 'boolean' | 'number' | 'null'
          ],
        filterFn:
          COLUMN_FILTER_FUNCTIONS[
            property.type as 'string' | 'boolean' | 'number' | 'null'
          ],
        columnFilterModeOptions: [
          ...COLUMN_FILTER_MODE_OPTIONS[
            property.type as 'string' | 'boolean' | 'number' | 'null'
          ],
          ...(property.mandatory ? [] : OPTIONAL_FILTER_MODE_OPTIONS),
        ],

Good catch! I agree it’d be more consistent if all or none of these had custom types. Do you think we should add custom types for COLUMN_FILTER_FUNCTIONS and COLUMN_FILTER_MODE_OPTIONS to match COLUMN_FILTER_VARIANTS, or just remove the custom type from COLUMN_FILTER_VARIANTS? Curious to hear which approach you think would be clearer and easier to maintain!

[asuresh-code]

Good catch! I agree it’d be more consistent if all or none of these had custom types. Do you think we should add custom types for COLUMN_FILTER_FUNCTIONS and COLUMN_FILTER_MODE_OPTIONS to match COLUMN_FILTER_VARIANTS, or just remove the custom type from COLUMN_FILTER_VARIANTS? Curious to hear which approach you think would be clearer and easier to maintain!

I think using the inbuild record type, but with custom types would be a good approach. We get stricter type enforcement for COLUMN_FILTER_FUNCTIONS and COLUMN_FILTER_MODE_OPTIONS, without having to create a specific custom type for every constant. The only downside of this approach is that you lose the strict filter variant enforcement on data types (so it would allow a date-time variant for booleans), but I don't think it's really necessary to enforce that; I think in development and code reviews we could make a judgement on if a new filter variant is suitable.

type DataTypes = 'boolean' | 'string' | 'number' | 'null' | 'datetime' | 'date';

type FilterVariant =
  | 'select'
  | 'text'
  | 'range'
  | 'autocomplete'
  | 'datetime-range'
  | 'datetime'
  | 'date-range'
  | 'date'
  | 'checkbox'
  | 'time'
  | 'multi-select'
  | 'range-slider'
  | 'time-range'
  | undefined;

export const COLUMN_FILTER_VARIANTS: Record<DataTypes, FilterVariant> = {
  boolean: 'select',
  string: 'text',
  number: 'text',
  null: 'text',
  datetime: 'datetime-range',
  date: 'date',
};
export const COLUMN_FILTER_FUNCTIONS: Record<DataTypes, MRT_FilterOption> = {
  boolean: 'fuzzy',
  date: 'betweenInclusive',
  datetime: 'betweenInclusive',
  string: 'fuzzy',
  number: 'betweenInclusive',
  null: 'fuzzy',
};
export const COLUMN_FILTER_MODE_OPTIONS: Record<DataTypes, MRT_FilterOption[]> =
  {
    boolean: ['fuzzy'],
    date: ['between', 'betweenInclusive', 'equals', 'notEquals'],
    datetime: ['between', 'betweenInclusive'],
    string: [
      'fuzzy',
      'contains',
      'startsWith',
      'endsWith',
      'equals',
      'notEquals',
    ],
    number: ['between', 'betweenInclusive', 'equals', 'notEquals'],
    null: [
      'fuzzy',
      'contains',
      'startsWith',
      'endsWith',
      'equals',
      'notEquals',
    ],
  };

[joshuadkitenge]

Your approach using Record<DataTypes, FilterVariant> and Record<DataTypes, MRT_FilterOption> is a practical solution. Leveraging TypeScript’s Record type with DataTypes and FilterVariant gives good type safety and flexibility while avoiding the need for creating overly specific custom types for each constant.

Also, given that boolean types can already be set to date filters in MRT, strict enforcement here might not be necessary. This more open-ended setup will let developers choose and adjust filter types with their judgment, especially in cases where filter usage might change as the UI evolves.

This can be used instead of
type FilterVariantType = MRT_ColumnDef<MRT_RowData>['filterVariant'];

type FilterVariant =
  | 'select'
  | 'text'
  | 'range'
  | 'autocomplete'
  | 'datetime-range'
  | 'datetime'
  | 'date-range'
  | 'date'
  | 'checkbox'
  | 'time'
  | 'multi-select'
  | 'range-slider'
  | 'time-range'
  | undefined;

[joshuadkitenge]

Looks good to me!

Please wait until PR #1046 is merged into develop, then go ahead and merge this PR.

One thing I noticed: for boolean fields, we should set the select options explicitly to ['Yes', 'No'] using filterSelectOptions: ['Yes', 'No']. Currently, the options are dynamically generated, so if all values are false, only "No" appears in the list. This should be addressed separately