888-685-3101, ext. 2

Filter by document dates in GSA (Google Search Appliance)

by | Jul 30, 2014 | Blog, Enterprise Infrastructure, Portals

We recently came across an issue in a client’s environment where they were leveraging Google Search Appliance for search. The client was trying to filter documents by last updated date and filtering documents by document dates was not working at all.

GSA provides a very easy way to define a document date field. All you have to do is go to crawl-and-index -> Document Dates and add the meta-data field to the document dates configuration according to this document provided by Google: http://www.google.com/support/enterprise/static/gsa/docs/admin/70/admin_console_help/crawl_sort.html

However, this did not work in the client’s environment.

Please note that the metadata field the client was using to sort the documents was:

gsa-article-publish-date

Here are the approaches we tried to use to sort the documents that did not work:

  1. We tried to filter results by using queryterm inmeta:gsa-article-publish-date:daterange:2013-07-01.. the results did not come back filtered based on the criteria.
  2. We also tried queryterm :daterange:2013-07-01.. this did not work either.

What was causing the problem:

The problem was with the hyphens the client had in the metadata field they were using to filter the results. The hyphens in the metadata field were causing the filtration feature to break on the GSA.

The Solution:

As a work around, we changed the query string by encoding the hyphen (-) and replacing it with %2d. This worked as expected.

We modified the query term from

inmeta:gsa-article-publish-date:daterange:2013-07-01..

to

inmeta:gsa%2darticle%2dpublishe%2ddate:daterange:2013-07-01..

to make filtering work in the environment.

In conclusion: If you have access to the application and if you have the resources to change the meta-tag everywhere in your application to a non-hyphenated version, that would be the ideal fix. However, if changing the meta-tags is too work, then a work around for the issue is to change the query term to use the Hexadecimal equivalent for special characters in the query term (in our case, %2d instead of hyphens) and this will work as expected.