App Within Minutes - Short text fields not searchable?

I had previously created an “App Within Minutes” app for keeping a list of documents. The fields I added are 3 short text fields and one page content field.

My question/problem is, are the short text fields supposed to be searchable/filterable with partial strings?

For example, if I have 3 entries with a field value of “ax1”, “bx2”, “bx3”, then if I add just a “b” into the filter field, I would expect bx2 and bx3 to be listed.

Instead, what happens is, I can only find the entries if I type in the exact name, e.g. “bx3” returns only the bx3 entry.

The default page name field works as expected, just typing in a substring returns those pages that match that substring - which is what I expected the short text fields filtering to behave.

The funny thing is, is I vaguely recall that this worked before, but it is not working now.

Am I mis-remembering? Or are my short text field searches no longer working as expected?

If they are not working, does anyone have any suggestions on how I an go about debugging this? I’ve already recreated the solr text index in case that was the problem.

Oh the xwiki extensions page works exactly in the way I remember my App Within Minutes app used to behave.

Any help or advice would be greatly appreciated.

Edit: Xwiki 13.6 under debian

Some examples, in case it wasn’t clear

1/ A simple list of scanned documents that we want to be able to find by key word searching:
Screenshot 2021-08-10 at 17.24.22

2/ Substring searches on the Page Title work as expected:
Screenshot 2021-08-10 at 17.23.58

3/ Searching for substrings in the next field doesn’t work (I even tried * as a wildcard).
Screenshot 2021-08-10 at 17.25.03

4/ Exact matches are fine, but not practical.
Screenshot 2021-08-10 at 17.25.14

4/ Same applies to the Matter field - substring searches here are even more important.
Screenshot 2021-08-10 at 17.25.27

I swear that I remember the substring searches working in the past. Am I just misremembering? Or is something broken in my system?

Both fields are “Short Text”

Editing the app page as wiki shows the following:

#set ($columnsProperties = {
  'doc.title': {"link":"view","type":"text"},
  'Client': {"type":"text"},
  'Job': {"type":"text"},
  'Volume': {}
#set ($options = {
  'className': 'Main.E-library (Bibles, Books & Prospectuses).Scanned Bibles.Code.Scanned BiblesClass',
  'translationPrefix': 'scanned bibles.livetable.',
  'tagCloud': true,
  'rowCount': 50,
  'maxPages': 10,
  'selectedColumn': 'doc.title',
  'defaultOrder': 'desc'
#set ($columns = ['doc.title', 'Client', 'Job', 'Volume'])
#livetable('scanned bibles' $columns $columnsProperties $options)

Again, any thoughts, hints, ideas or corrections to my memory would be appreciated. Otherwise I’ll have to convert this app to a live table. Ugh.

No suggestions from anyone?

@pdwalker please report it in . It’s a regression caused by . It affects 13.5-rc-1 and 13.4.1. Mark it as Blocker.

I checked the live table results URL by adding &sql=1


and it seems the query is properly generated:

, BaseObject as obj , StringProperty as prop_shortText1 where and obj.className = :className and doc.fullName not in (:classTemplate1, :classTemplate2) and = and = :prop_shortText1_id_name and (upper(prop_shortText1.value) like upper(:prop_shortText1_value_1)) order by lower(doc.title) asc, doc.title asc

especially the:

upper(prop_shortText1.value) like upper(:prop_shortText1_value_1)

The problem is the value of the :prop_shortText1_value_1 parameter which is exactly the typed filter value, e.g. “u” instead of “%u%”. I commented on XWIKI-18661: Impossible to filter panel type or category with empty v… · xwiki/xwiki-platform@a5469d5 · GitHub .

1 Like

Hi @mfloreae, The answer is much appreciated. I really was worried that I was remembering something that didn’t actually happen.

Also, you’ve just given me the hint that I can use ‘%’ as a wildcard character to make it work in the meantime.

I should have thought of that sooner. I guess I’ve gotten too spoiled with all the user friendly user interfaces we have today.

Thank you!

Yes but don’t get used to it :slight_smile: we need to fix this ASAP.