Is your proposal related to a problem?

In the Table widget's filter panel, the value field is always a plain text input. This is the same input even when the selected column is a Date Picker, a Single-select, or a Multi-select (tag) column. Users have to type the value as free text, which is error-prone (typos, wrong date format, options the user doesn't know by exact value).

It is also not possible to properly filter a Multi-select (tag) column today. The current operators (equals, contains, etc.) don't express what users actually want for tag columns: "row's tags include any of X" or "row's tags include none of X".

Describe the solution you'd like

Make the filter row's value input match the selected column's type, and add two operators for multi-select columns.

For multi-select columns, two new operators are added next to the existing is empty / is not empty:

• contains any — keep rows that share at least one of the picked tags
• contains none — keep rows that share none of the picked tags

The single-select and multi-select option lists use the same resolution the table cells already use, so if the column has dynamic options the filter offers exactly the same options the user sees in the cell.

What is not changing:

• Any column type that isn't Date / Single-select / Multi-select keeps the plain text input.
• No new dependencies.
• The change is bounded to the Table widget's filter folder (frontend/src/AppBuilder/Widgets/NewTable/_components/Header/_components/Filter/): 4 small modifications and 1 new FilterValueInput.jsx component.

Describe alternatives you've considered

• Keep the plain text input and document the expected value format. This doesn't help multi-select columns at all and gives no good answer for columns whose options come from dynamic data.
• Only add the multi-select operators, without changing the value input. The operators would still take a free-text value, which defeats the point for tag columns.
• If reviewers want a smaller PR, the change splits cleanly into single-select first and multi-select as a follow-up. Happy to split.

Demo

If the feature is approved, would you be willing to submit a PR?

Yes. The change is implemented locally on a branch off develop (5 files, no dependency changes, eslint-clean) and is ready to open once an issue is assigned.