[Koha-bugs] [Bug 32707] ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields)

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32707

--- Comment #38 from Janusz Kaczmarek <januszop at gmail.com> ---
Created attachment 163893
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=163893&action=edit
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate =
1) for identifiers (and some other fields)

Koha with Zebra prevented auto truncation in some circumstances -- see
the first return for ccl inside C4::Search:: buildQuery, before applying
auto truncation, and setting $auto_truncation = 0 for some search
fields.

Koha with ElasticSearch applies auto truncation for all search fields,
not paying attention to these special cases when it should not be done.
This leads to various problems as described in bug 26508, 26608, etc.

The solution would be to prevent auto truncation for certain search
fields, above all – the identifiers.  In addition, under no
circumstances should a search field other than of text type be truncated
(an attempt to truncate would generate an exception from ElasticSearch,
e.g. number_format_exception for integer).

Test plan
=========

0. Use the test data sample provided in the bug report. Comment 16 in
   the ticket.

Scenario A (authority)
----------------------
1. Enable Elasticsearch engine.
2. Have like 100+ bibliographic records and properly linked authority
   records.
3. Reindex ElasticSearch if needed.
4. Enable QueryAutoTruncate systempreference.
5. Find the authority record #1 and note the number of linked biblio
   records.
6. Show the detail of authority #1 and compare the number of linked
   biblio records.
7. If in the database there are authority records with ids =~ /^1/ (i.e.
   10, 11, 12, ..., 100, 101, ...) linked to the biblio records you get
   two different numbers of linked records.
8. Also, as lists of linked biblio records (via link: Used in N
   record(s) from results view and detail view) you will get two
   different sets of biblio records.  In particular, on the list generated
   from detail view (authorities/detail.pl?authid=1) you will get biblio
   records that are in fact not linked to the auth #1 (the list is
   generated with &q=an:1).
8.99. Skip to scenario B and come back here after finishing to not have
to unapply the patches and restart services for nothing.
9. Apply this patch.
10. Counts and list of linked biblios should be ok.

Scenario B (analytics)
----------------------
1. Enable Elasticsearch engine.
2. Have three monographic bibliographic records with 001 = 1, 10, 100
   (i.e. =~ /^1/).
3. Have an analytical record with 773 $w = 1 (in the test data set - biblio
896).
4. Enable QueryAutoTruncate and UseControlNumber systempreference.
6. Find the analytical record and click on the link generated from 773,
   i.e. (In: ... --> catalogue/search.pl?q=Control-number:1).  You should see
   a list of 100+ records (001 = 1, 10, 100) instead of one (001 = 1).
7. From the biblio # 1 try to go to the analytice records (with Show analytics
   link) - you should get 60+ records with from different host records (773 $t)
   -- instead of one.
8. Apply this patch. Make sure that control-number and record-control-number
   are included in ESPreventAutoTruncate syspref.
9. Repeat steps 6 and 7.  You should arrive at the right host record in p. 6
   and at one analytical records when looking for analytical records in p. 7
   (or more than one, but right, if you modified the test data set).

Signed-off-by: Victor Grousset/tuxayo <victor at tuxayo.net>

-- 
You are receiving this mail because:
You are watching all bug changes.