Lookup Fields/Formulas should be filterable/colorable/aggregatable in the grid view
Problem Statement
Currently lookup fields and formulas with the array type are not filterable, colourable or have any aggregates applied over them.
Benefits and risks
Benefits
- All other field types let you filter and it is an important way of working with Baserow
Risks
- Filters applied on lookups need to work over JSONB arrays which might be complex (or easy) not sure.
Proposed solution
- Unknown
UI/UX Design Required
-
None (No UI/UX work required for this feature)
Priority/Severity
-
Medium (This will bring a good increase in performance/productivity/usability)
Specifications:
Every lookup field is a BaserowFormulaArrayType
where the subtype is the type of the looked-up field. For example, if we're looking-up a text
field in the related table, the resulting formula will be of type array
with formula_array_type=text
The idea here is to make lookups
filterable by enabling the available filters for the formula-array-type, and to includeall the rows with at least one linked row matching the filter in the results.
For example, let's say we have tableA
with a text field Name
and 2 rows with a
and b
as values for that field.
In tableB
, we have a link field to tableA
and 3 rows:
- row1 with a link to
a
- row2 with a link to
b
- row3 with a link to
a
andb
In tableB
, we should:
- be able to select all the filters available for the
formula_array_type
, In this case, all the filters available for thetext
field type - filter rows in
tableB
if the field intableA
match the filter value for at least one of the linked rows. In this example if, iffilter_type="equal"
andvalue="a"
, the results should includerow1
androw3
Acceptance criteria:
- We should use the existing filter types (not adding new ones) and implement the right common logic to handle arrays of the various types properly.
- Every field type that can be looked up should be filterable, although this can be split into multiple MRs if it makes sense.
Filter types not implementing the
NotViewFilterTypeMixin
should return a row if any of the looked-up values match the filter value. - each new type/subtype added should be tested
- nice to have: at least one test should fail if a new subtype is added but it's not covered by a test (see
test_ensure_all_multi_step_filter_type_and_operators_are_tested
)