TPAC: Address some search syntax leaks in links user/dbs/pound_facets
authorDan Scott <dscott@laurentian.ca>
Thu, 11 Oct 2012 04:56:40 +0000 (00:56 -0400)
committerDan Scott <dscott@laurentian.ca>
Thu, 11 Oct 2012 05:12:19 +0000 (01:12 -0400)
commit3359b33eb3bb239874c07a84340c99ec8afe13b6
tree42e0935cb7499414787aa945421268e247e92fd9
parentb273c345ce2731cd605eeae7b03ee64e368c6c84
TPAC: Address some search syntax leaks in links

Expand the list of filtered characters to cover all of the special
characters documented for the Evergreen search grammar
(http://evergreen-ils.org/dokuwiki/doku.php?id=documentation:technical:search_grammar)
when generating links in the TPAC so as to avoid inadvertently launching
filtered searches when a user clicks on something that should just be a
display value.

For example, if a title includes "Presenting a subject: tips for
consultants", it should _not_ launch a search for "subject" containing
"tips for consultants".

This commit addresses most of the link problems in the record
display, as well as the author links in the search results table.

Still problematic are the facets (which seem to rely on exact matching,
such that filtering out the problematic characters is itself
problematic) and autocomplete (which requires modifying the Autocomplete
Dojo widget).

In addition, this commit makes the series code actually display, as it
was using a non-standard method to attempt to return the results from
the BLOCK (and failing). Also, it makes the links for authors in the
record details match the MODS32 definition for personal name parts and
only use the "acdq" subfields. This enables a click on the link to
actually return results; previously, in the case where the author field
included (for example) a subfield "g" value, that value would be
included in the generated link and would likely lead to 0 hits.

For authors, we substitute with a space rather than just eliding the
substituted value. Authors are particularly likely to have dates like
1899-1978; "1899 1978" matches, but "18991978" will not.

Perhaps we should take the same approach with the others, or break down
the search/replace logic a little further (for example, we could remove
the "-" only if it is preceded by a space or is at the start of the
string and is followed immediately by a character, and preserve it if it
is surrounded by digits). But this seems to take us pretty far down the
road of less negatively surprising results.

Signed-off-by: Dan Scott <dscott@laurentian.ca>
Open-ILS/src/templates/opac/parts/record/authors.tt2
Open-ILS/src/templates/opac/parts/record/series.tt2
Open-ILS/src/templates/opac/parts/record/subjects.tt2
Open-ILS/src/templates/opac/parts/result/table.tt2