]> git.evergreen-ils.org Git - Evergreen.git/commit
TPAC: Address some search syntax leaks in links
authorDan Scott <dscott@laurentian.ca>
Thu, 11 Oct 2012 04:56:40 +0000 (00:56 -0400)
committerBill Erickson <berick@esilibrary.com>
Tue, 30 Oct 2012 16:27:32 +0000 (12:27 -0400)
commita58bb07326a5cfe54adbe3917edbf80b360e5421
treefc240aac1b058b6b7b2b3da1c5030477ab3392e7
parentea560cb339f69b05f5ec93231219875fa96e00b0
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>
Signed-off-by: Bill Erickson <berick@esilibrary.com>
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