Filtering custom columns on a folderish document with custom page provider
We have a section in Nuxeo for employee photos. These files are their own doctype contained in a custom, folderish doctype called “Library.” For this Library, I have created a custom page provider with predicates and aggregates of schema fields relevant to these types of documents. I am having an issue with the filters for some of the fields though.
For example, every employee has an employee ID, so I have a schema/field for it called employee:employee_id
(set as a string since IDs can contain letters or numbers). In the view of the parent container (Library) there is code to add a search filter in table view:
<nuxeo-data-table-column
name="Employee ID"
field="employee:employee_id"
sort-by="[[_displaySort(document, 'employee:employee_id')]]"
filter-by="employee_employee_id"
filter-expression="$term*"
flex="25">
<template>[[item.properties.employee:employee_id]]</template>
</nuxeo-data-table-column>
That field is a predicate in my custom page provider, with a full text operator. Here is the setup:
The issue I have is that for some IDs that all all numbers the filter works as expected and filters correctly as a user types in characters. However, for any of the IDs that start with letters the filter doesn't find anything at all. What could be causing this issue? I've tried different config settings, but I'm missing something (likely simple). Any guidance would be appreciated. Thanks.
I've attached a video demo of the search not working for an ID that starts with letters.
Phil Ludlow I know the thread stopped a while ago, has your issue been resolved? My 2 cents: you may need to update ES mappings, title “Making STARTSWITH work” sounds promising ;-) https://doc.nuxeo.com/nxdoc/configuring-the-elasticsearch-mapping/#making-startswith-work-with-a-custom-field
The "fix" for us was adding the operator of "wildcard" on the predicate editor. This helped so that we could put characters or numbers in the search filter and it would work as expected. The only deficiency we have right now is that it is case-sensitive. This likely could all be a bit more improved, but for the time-being it works well enough.
STARTSWITH
search operator?STARTSWITH
then filtering doesn't work at all—it doesn't even work for the numbers that were working before. Also, it seemsSTARTSWITH
should only be used for a path-type value?