feat: allow multiple filter values, fixes #7328

[paulroub]

Summary

Allows a collection filter to match one of a number of values; still allows the existing single-value syntax, as well as an array of values.

Need to manage a collection that's a combination of existing categories (rather than re-categorize all those posts).

Test plan

• Added a unit test for the array variation, existing (non-array) tests still path.
• Tested against my collections, with single-value, single-element-array and multiple-element-array variations all working as expected.

Checklist

Please add a x inside each checkbox:

• I have read the contribution guidelines.
• I have added a documentation update PR at feat: allow multiple filter values decap-website#92

A picture of a cute animal (not mandatory but encouraged)

[martinjagodic]

@paulroub, thanks for your contribution. Before we review, can you please ensure the tests are passing?

[paulroub]

@martinjagodic Fixed the linting issues, along the way had to tell stylelint to ignore backend.ts as it was trying to parse a cast as CSS and was not happy with the result. No actual styles in this file, of course, so that should be harmless.

[paulroub]

Rebased on current main, confirmed npx run test:all still succeeds.

[Copilot]

Pull Request Overview

Adds the ability for collection filters to match against multiple values by updating the value type, normalizing inputs, and enhancing the filter logic.

• Expand FilterRule.value to accept arrays, Immutable List, or typed records
• Normalize raw filter and field values via a new valuesAsArray helper
• Update filterEntries to use normalized arrays and add a corresponding unit test
• Ignore backend.ts in Stylelint to prevent lint failures on new code

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
packages/decap-cms-core/src/types/redux.ts	Broaden FilterRule.value type to support multi-value inputs
packages/decap-cms-core/src/backend.ts	Implement valuesAsArray and update filterEntries for arrays
packages/decap-cms-core/src/tests/backend.spec.js	Add test covering array-based filter values
.stylelintrc	Include src/backend.ts in lint ignore list

Comments suppressed due to low confidence (1)

packages/decap-cms-core/src/tests/backend.spec.js:98

• This test covers plain arrays but doesn't verify behavior when value or entry.data[field] are Immutable List or StaticallyTypedRecord<List<string>>. Add tests for those types to ensure full coverage of the new normalization logic.

    it('filters multiple values', () => {

[Copilot]

The check for toJS comes before distinguishing Immutable List instances, so Lists (which also have toJS) will be treated as records. This leads to invoking .toJS().toArray() on a plain JS array, causing a runtime error. Consider using List.isList(rawValue) first, then detect records by checking for toJS.

Suggested change

	if ((<StaticallyTypedRecord<List<string>>>rawValue).toJS) {
	if (List.isList(rawValue)) {
	values = rawValue.toArray();
	} else if ((<StaticallyTypedRecord<List<string>>>rawValue).toJS) {

[martinjagodic]

@paulroub it's been a while, I hope this is still relevant to you.

When I try this with my test config, the collection fails to load entries - even before I tried the list of filters. See screenshot below.

I also have an idea of extending this further by adding an operator like with the condition field.

Condition example:

condition: {
  field: layout,
  value: list-filters,
  operator: '!='
}

Maybe we should combine these functions, as it's potentially the same feature on a different level.

[paulroub]

When I try this with my test config, the collection fails to load entries - even before I tried the list of filters. See screenshot below.

I'm so far unable to reproduce this -- any chance you could share your test config?

[paulroub]

When I try this with my test config, the collection fails to load entries - even before I tried the list of filters. See screenshot below.

Reproduced, fixed, added a test case. We were assuming the presence of the filtered-on field on all
entries in the collection. Now just failing the match if (e.g.) we're filtering on "category" but a post doesn't have one.

I also have an idea of extending this further by adding an operator like with the condition field.

I had considered that as well, and poked at it a bit. I hadn't considered extending the syntax, that would make things much more doable.

Perhaps a follow-on? This version seems useful on its own.

[martinjagodic]

Great, thanks! We can do that in a later PR, I agree. If all is ok now, we should merge this for the 3.9 release.