[IMPLEMENTED] Filtering by Component fields in the UI

[slalFe]

Hello,

We’re making use of a Components field, however it was just noticed that we cannot filter by the fields in the Component with the UI. If the component’s field is of text type it is included in the full text search but is still not available from the filter selection, and I am wanting to filter on the value of a reference’s field’s value.

For example:
Shop Visit (schema)

• Shop Name (included in full text search, available as a filter option)
• Basket (component schema)
  • Basket Name (included in full text search, not available as a filter option)
  • Fruit (reference field of component schema)
    • Apple (content of another schema)
      • Apple Name (not included in full text search, not available as a filter option)

I cannot use the UI to filter by ShopVisits that had Apples in the Basket.

Please do let me know if I am missing something, and also please let me know if this isn’t easily possible as we may need to change our implementation!

[Sebastian]

I have just seen that the UI is broken here. It should be possible with odata filters, e.g. when you type something like

$filter=data/component/iv/field eq ‘foobar’ in the search bar.

[slalFe]

Hello,

Thanks for a speedy response (also thanks for the fix for default values applying to component fields, we’ve tested against latest master and it is working well).

Closest I can get at the moment (will have another look in the morning) with OData query is:
$filter=data/Basket/iv/contents eq ‘773b9501-a3a7-4e5c-9e4a-b89f6d55fd13’

But that relies on user knowing content ID of thing they are searching for. I’m not sure that there’s a way of resolving the reference IDs as part of the query?

"data": {
        "ShopName": {
            "iv": "Food Shop"
        },
        "Basket": {
            "iv": {
                "schemaId": "4c24ec19-de9a-47a0-b827-c95cdd8e6d6c",
                "BasketName": "Test",
                "contents": [
                    "773b9501-a3a7-4e5c-9e4a-b89f6d55fd13"
                ]
            }
        }
    }

Best regards,
Paul

[Sebastian]

I will work on this.

[Sebastian]

Hi,

I have implemented this in the master branch. It was actually bigger than expected, because the big issue was that the UI had its own model for the query UI which was causing inconsistencies to the backend.

Therefore I have introduced a wide range changes in the backend:

1. New model for filters and converter to EDM (OData). Before there were 2 models: JSON Model and EMD Model (OData). Now we only have to maintain one place for this.
2. New endpoint to fetch the model in the UI and use it to show the UI filtering View.
3. Fixes in the backend to improve union types. When you use components, it can be possible that a field in the database can have multiple types, e.g. either String or Number. With this improvement the query parser for JSON queries checks all alternatives to determinate whether a query is valid or not.

These improvements are part of the master branch but not part of a release or deployment yet.