OpenKM Community ed. Advanced Search Not Working

[ncpeiarchive]

I recently installed OpenKM community edition 6.3.9 on a server running Ubuntu 20.04, Tomcat 8.5.24, and PostgreSQ. I am enjoying all of the features that OpenKM provides but I seem to be having difficulty using the advanced search feature. Using basic search with fulltext is able to show results but performing any search in Advanced View does not work. I try searching in the Taxonomy context with only name, only content, or only user, or also searching for PDF mimetype within a folder that has many PDFs -- no advanced search ever returns a result. The advanced search flickers an "updating search" popup very briefly and does not show any results. Nothing in the debug console or Catalina logs either.

I've looked elsewhere on the forums and tried other suggestions first. I queried the database and ensured all documents had text extraction and then rebuilt my Lucene indexes. I also read that sometimes the search feature does not interact well with custom property groups, so I tried with a file that had no property groups added. I am just baffled because basic search works on all of the fields but the advanced search does not work on any.

Am I doing something wrong? Is this a limitation of community edition? Any suggestions?

[jllort]

Really exist a document named quit or you want to search by content and filled wrong field?
Anyway in case basic search the application applies wilcards internally, in your case you should search by "quiet*" -> take a look here https://docs.openkm.com/kcenter/view/ok ... earch.html

[ncpeiarchive]

Thanks for the quick reply. As seen in the first screenshot, there is a file named "2013_One_Country_One_Quilt_Application.pdf" that does contain the word "Quilt" in its text as well. On the advanced search, I tried both the content and name search separately, with and without the wildcard as you suggested, with no results either time. I also tried using the advanced tab and searching for all PDFs in the folder that holds that document and got no results. No variation of any search parameters returns any results for advanced searches on my repository with over 2,000+ documents.

[jllort]

in name field you should quering with *quilt

[ncpeiarchive]

*quilt, quilt*, and *quilt* yield no results. Tried this with each of the words in "One Country One Quilt Application" and no results for any search.

[jllort]

Go to administration > tools > rebuild indexes and then Lucene indexes ( that will rebuild entire lucene search indexes. Sometimes after and upgrade it is mandatory doing it ).

[ncpeiarchive]

I rebuilt the Lucene indexes and still no luck. My basic search is still working as intended but no results for advanced search.

[jllort]

Share screenshots again:
1- what works
2- what not works
3- document content and name

[ncpeiarchive]

I created a new text file to demonstrate the issue. The text file is located in /okm:root/testing and is named Lorem_Ipsum.txt. It contains a brief intro followed by five generated paragraphs of Lorem Ipsum text. It has a custom metadata group called "File Info" that adds "File Date" and "File Author" fields to represent the original date and author of the file rather than the internal author and update date set during the file upload.

Screenshot 1 shows the file in taxonomy view and you can confirm the file contents, metadata, and location.

Screenshot 2 shows a successful basic search for the term "lorem" which brings up the text contained within the file.

Screenshot 3 shows a failed search when searching for a file with "lorem*" in its content. This is the same result for any combination of asterisk before or after the "lorem" term. When search is clicked, a blue pop-up displays extremely briefly with the text "Updating search" and then disappears immediately.

Screenshot 4 and 5 shows the same failed advance searches for name and file type, respectively. No search results for any Advanced Search ever returns results.

[jllort]

Add an issue here https://github.com/openkm/document-mana ... tem/issues it seems a bug