Bug 32707 - Elasticsearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields)
Summary: Elasticsearch should not auto truncate (even if QueryAutoTruncate = 1) for i...
Status: Pushed to main
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching - Elasticsearch (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal with 10 votes (vote)
Assignee: Janusz Kaczmarek
QA Contact:
URL:
Keywords: no-sandbox, release-notes-needed
: 24129 26508 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-01-24 10:52 UTC by Janusz Kaczmarek
Modified: 2024-04-05 15:40 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.05.00


Attachments
[PATCH] Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (6.11 KB, patch)
2023-01-24 10:56 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Add 'ESPreventAutoTruncate' preference (4.43 KB, patch)
2023-10-27 21:50 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (6.60 KB, patch)
2023-10-27 21:50 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Unit tests (6.25 KB, patch)
2023-10-27 21:50 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
biblio and auth data sample to test the patch (777.99 KB, application/octet-stream)
2024-01-15 13:02 UTC, Janusz Kaczmarek
Details
biblio and auth data sample to test the patch (905.91 KB, application/x-compressed)
2024-03-22 22:26 UTC, Janusz Kaczmarek
Details
Bug 32707: Add 'ESPreventAutoTruncate' preference (4.50 KB, patch)
2024-03-22 22:40 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (6.60 KB, patch)
2024-03-22 22:40 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Unit tests (6.25 KB, patch)
2024-03-22 22:40 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (7.01 KB, patch)
2024-03-24 14:06 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Add 'ESPreventAutoTruncate' preference (4.35 KB, patch)
2024-03-25 15:04 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (7.01 KB, patch)
2024-03-25 15:04 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Unit tests (5.98 KB, patch)
2024-03-25 15:04 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Unit tests (6.03 KB, patch)
2024-03-26 02:20 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review
Bug 32707: Add 'ESPreventAutoTruncate' preference (4.41 KB, patch)
2024-03-26 02:20 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (7.22 KB, patch)
2024-03-26 02:20 UTC, Victor Grousset/tuxayo
Details | Diff | Splinter Review
Bug 32707: Add 'ESPreventAutoTruncate' preference (4.44 KB, patch)
2024-03-26 09:53 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (7.39 KB, patch)
2024-03-26 09:53 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Unit tests (6.08 KB, patch)
2024-03-26 09:53 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 32707: Add 'ESPreventAutoTruncate' preference (4.50 KB, patch)
2024-03-29 17:32 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 32707: ElasticSearch should not auto truncate (even if QueryAutoTruncate = 1) for identifiers (and some other fields) (7.44 KB, patch)
2024-03-29 17:32 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 32707: Unit tests (6.14 KB, patch)
2024-03-29 17:33 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Janusz Kaczmarek 2023-01-24 10:52:55 UTC
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).
Comment 1 Janusz Kaczmarek 2023-01-24 10:56:49 UTC
Created attachment 145606 [details] [review]
[PATCH] 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
=========
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).
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.
4. Reindex ElasticSearch if needed.
5. 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).
7. You should see a list of three records (001 = 1, 10, 100) instead of
   one (001 = 1).
8. Apply this patch.
9. Repeat step 6.  You should arrive at the right host record.
Comment 2 Amaury GAU 2023-01-24 14:35:19 UTC
Hi, 

For now, I tried Scenario A : 


1. Checked linked authorities with Zebra : OK
2. Change to ES : OK
3. Reindex Es on the sandbox : OK
4. Expected authorities to be properly linked, but they weren't, even though the reindexation worked : 

"
[11721] Checking state of biblios index
[11721] Dropping and recreating biblios index
[11721] Checking state of authorities index
[11721] Dropping and recreating authorities index
[11721] Indexing biblios
[...]
[11721] Indexing authorities
[...]
[11721] Commit complete
[...]
[11721] Total 6635 records indexed
"

Did I miss something on the way here ?
Comment 3 Janusz Kaczmarek 2023-01-27 12:18:00 UTC
(In reply to Amaury GAU from comment #2)
> Hi, 
> 
> For now, I tried Scenario A : 
[...]
> 4. Expected authorities to be properly linked, but they weren't, even though
> the reindexation worked : 
[...]


I'm not sure what to answer...  What does it mean that authorities are not properly linked.  In what sense?  Are there no $9 subfields in the biblio heading fields or something else...?  Before or after applying the patch?  Could you please be more specific.

Cheers - Janusz
Comment 4 Fridolin Somers 2023-02-17 08:39:57 UTC
Looks like this is related to Bug 24143

Please have a look.

Don't you think we should avoid all query changes (truncation, ...) for search in identifiers ?
Comment 5 Janusz Kaczmarek 2023-02-17 12:36:22 UTC
(In reply to Fridolin Somers from comment #4)
> Looks like this is related to Bug 24143
> 
> Please have a look.
> 
> Don't you think we should avoid all query changes (truncation, ...) for
> search in identifiers ?

Yes, it is related.  But Koha with Zebra queries with operands like sn:<biblionumber>, an:<authid> will not be autotruncated: in C4::Search they will be classified as ccl queries (lines 1234nn of the current master) and, as a consequence, buildQuery will return in line 1345 (if ( $query =~ /^cql=/ ) ...), before applying auto truncation.  And auto truncation of standard identifiers like ISBN, ISSN, where index name is not a part of operand, is prevented by line 1421nn.

This behaviour is not reflected in ES build_query_compat.


And yes, I think we should avoid auto truncation and other automatic query modifications for identifiers.  A proposal of a list of identifiers is hardcoded in the patch, in the method _is_safe_to_auto_truncate:

barcode biblioitemnumber control-number control-number-identifier date-of-acquisition date-of-publication date-time-last-modified host-item-number identifier-standard isbn issn itemnumber itype koha-auth-number lc-card-number local-number number-local-acquisition other-control-number record-control-number

Please, feel free to correct/extend the proposed patch.
Comment 6 Katrin Fischer 2023-10-27 10:27:46 UTC
*** Bug 24129 has been marked as a duplicate of this bug. ***
Comment 7 Janusz Kaczmarek 2023-10-27 11:06:58 UTC
After having a conversation with Nick, I am currently refactoring the patch.  In a short time I will post it here.
Comment 8 Janusz Kaczmarek 2023-10-27 21:50:44 UTC
Created attachment 158007 [details] [review]
Bug 32707: Add 'ESPreventAutoTruncate' preference

This patch adds a new 'ESPreventAutoTruncate' preference allowing to define
Elasticsearch search fields that should not be autotruncated when 'QueryAutoTruncate'
is active (e.g. barcode).
Comment 9 Janusz Kaczmarek 2023-10-27 21:50:46 UTC
Created attachment 158008 [details] [review]
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
=========

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).
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.
4. Reindex ElasticSearch if needed.
5. 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).
7. You should see a list of three records (001 = 1, 10, 100) instead of
   one (001 = 1).
8. Apply this patch. Make sure that record-control-number is included
   in ESPreventAutoTruncate syspref.
9. Repeat step 6.  You should arrive at the right host record.
Comment 10 Janusz Kaczmarek 2023-10-27 21:50:49 UTC
Created attachment 158009 [details] [review]
Bug 32707: Unit tests

NB in t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t,
I had to modify four existing test by changing Local-number:123456 to
Personal-name:donald -- since Local-number should never be
auto truncated according to the submitted patch.
Comment 11 Janusz Kaczmarek 2023-10-27 21:51:30 UTC
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
=========

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).
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.
4. Reindex ElasticSearch if needed.
5. 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).
7. You should see a list of three records (001 = 1, 10, 100) instead of
   one (001 = 1).
8. Apply this patch. Make sure that record-control-number is included
   in ESPreventAutoTruncate syspref.
9. Repeat step 6.  You should arrive at the right host record.
Comment 12 Katrin Fischer 2023-12-10 08:55:40 UTC
*** Bug 26508 has been marked as a duplicate of this bug. ***
Comment 13 Janusz Kaczmarek 2024-01-15 13:02:59 UTC
Created attachment 161035 [details]
biblio and auth data sample to test the patch

Since the biblio and auth data in ktd are not linked (and even not related), this can be a difficulty in testing the patch.  I am attaching 500 biblio records with almost 2,000 auth records already linked by subfield $9 in biblio heading fields. This data should allow you to test the patch according to the proposed scenarios.

Data import (in ktd):

./misc/migration_tools/bulkmarcimport.pl -a -d -file bug_32707_auths_sample.mrc
./misc/migration_tools/bulkmarcimport.pl -b -d -file bug_32707_bibs_sample.mrc
sudo koha-elasticsearch --rebuild -r -d -a -b kohadev
Comment 14 Victor Grousset/tuxayo 2024-02-22 18:50:22 UTC
Hi :)

> Scenario A (authority)
> 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.


In sample data an:1 isn't linked to anything and doesn't have a name.
I completed it with a name.
Then linked it to a 100$a of a record, replacing the current author.

When searching the auth name I get it, it tells me 1 linked record.
Auth details page tells me 1 linked record also.
Both are the same, so it fails to reproduce the issue :(
Auths 10 to 19 have linked records so it should cause the bug, right?
SearchEngine is indeed set to ES. I've started KTD with it and catalogue search is working.

Anything else to check to be able to reproduce?
Comment 15 Janusz Kaczmarek 2024-03-22 17:49:13 UTC
(In reply to Victor Grousset/tuxayo from comment #14)
> In sample data an:1 isn't linked to anything and doesn't have a name.
> I completed it with a name.
> Then linked it to a 100$a of a record, replacing the current author.
> 
> When searching the auth name I get it, it tells me 1 linked record.
> Auth details page tells me 1 linked record also.
> Both are the same, so it fails to reproduce the issue :(
> Auths 10 to 19 have linked records so it should cause the bug, right?
> SearchEngine is indeed set to ES. I've started KTD with it and catalogue
> search is working.
> 
> Anything else to check to be able to reproduce?

Hi! 

Sorry I've missed the message.  

That's somehow strange.  I just repeated the test scenario and it seems OK with the data provided. The authid #1 should be 110 $a Institute of Jesuit Sources (Boston). -- linked to 453 biblio records. 

While importing, did you delete the records provided with ktd (bulkmarcimport.pl with -d -fk switches)?

Anyway, I'm going to prepare a refreshed version of sample data, since the problem of linked analytical records is not well illustrated with the current set.
Comment 16 Janusz Kaczmarek 2024-03-22 22:26:02 UTC
Created attachment 163748 [details]
biblio and auth data sample to test the patch

Since the biblio and auth data in ktd are not linked (and even not related), this can be a difficulty in testing the patch.  I am attaching ca. 900 biblio records with ca. 3.200 auth records already linked by subfield $9 in biblio heading fields. This data should allow you to test the patch according to the proposed scenarios.

Data import (in ktd):

./misc/migration_tools/bulkmarcimport.pl -a -d -fk -file bug_32707_auths_sample.mrc
./misc/migration_tools/bulkmarcimport.pl -b -d -fk -file bug_32707_bibs_sample.mrc
sudo koha-elasticsearch --rebuild -r -d -a -b kohadev

NOTE: it is essential to remove the ktd biblio and auth data (-d -fk), as this data sample already has $9 subfields that will give correct test results if biblionumbers and authids start with 1.
Comment 17 Janusz Kaczmarek 2024-03-22 22:40:38 UTC
Created attachment 163749 [details] [review]
Bug 32707: Add 'ESPreventAutoTruncate' preference

This patch adds a new 'ESPreventAutoTruncate' preference allowing to define
Elasticsearch search fields that should not be autotruncated when 'QueryAutoTruncate'
is active (e.g. barcode).
Comment 18 Janusz Kaczmarek 2024-03-22 22:40:41 UTC
Created attachment 163750 [details] [review]
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
=========

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).
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.
4. Reindex ElasticSearch if needed.
5. 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).
7. You should see a list of three records (001 = 1, 10, 100) instead of
   one (001 = 1).
8. Apply this patch. Make sure that record-control-number is included
   in ESPreventAutoTruncate syspref.
9. Repeat step 6.  You should arrive at the right host record.
Comment 19 Janusz Kaczmarek 2024-03-22 22:40:44 UTC
Created attachment 163751 [details] [review]
Bug 32707: Unit tests

NB in t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t,
I had to modify four existing test by changing Local-number:123456 to
Personal-name:donald -- since Local-number should never be
auto truncated according to the submitted patch.
Comment 20 Victor Grousset/tuxayo 2024-03-23 04:26:01 UTC
> it seems OK with the data provided

Forget what is said, I missed that there was sample data provided in the ticket. (I'll add it in the test plan if I managed to test successfully)
I meant the sample data in Koha used in KTD. Hence your confusion.
Comment 21 Victor Grousset/tuxayo 2024-03-23 22:48:48 UTC
For test plan B, what is a clean way to have an analytical record with 773 $w = 1 ?
I after learning about analytics records, I tried to fill the gaps but in the end I still get 111 results with that link:
http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=Control-number:1
Which for step B 7. doesn't make sense.

---

Scenario A worked as expected :)

---

testing notes: after test data import + reindex, restart services to get the right counts of linked records.
Comment 22 Janusz Kaczmarek 2024-03-24 13:23:46 UTC
(In reply to Victor Grousset/tuxayo from comment #21)
> For test plan B, what is a clean way to have an analytical record with 773
> $w = 1 ?
> I after learning about analytics records, I tried to fill the gaps but in
> the end I still get 111 results with that link:
> http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=Control-number:1
> Which for step B 7. doesn't make sense.

Did you put "control-number" in the new ESPreventAutoTruncate preference?

(In the scenario description, I put incorrectly "record-control-number" :( )
Comment 23 Janusz Kaczmarek 2024-03-24 14:04:57 UTC
(In reply to Janusz Kaczmarek from comment #22)
> (In reply to Victor Grousset/tuxayo from comment #21)
> > For test plan B, what is a clean way to have an analytical record with 773
> > $w = 1 ?
> > I after learning about analytics records, I tried to fill the gaps but in
> > the end I still get 111 results with that link:
> > http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=Control-number:1
> > Which for step B 7. doesn't make sense.
> 
> Did you put "control-number" in the new ESPreventAutoTruncate preference?

I'm sorry--for analytical records to work correctly, you should put both: control-number and record-control-number in the ESPreventAutoTruncate preference.

Explanation: with searchfield control-number you go "up", i.e. from 773 $w to the host record; with record-control-number you go "down", i.e. from the host record the linked analytical records.

A patch with corrected test plan follows.
Comment 24 Janusz Kaczmarek 2024-03-24 14:06:24 UTC
Created attachment 163759 [details] [review]
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.

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).
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).
Comment 25 Victor Grousset/tuxayo 2024-03-24 22:08:42 UTC
> Did you put "control-number" in the new ESPreventAutoTruncate preference?

Oh no I forgot to updatedatabase >_<

Still, without patch, I should get 3 results, not 111. That's why my improvisation in making the analytical records might be wrong.

Ok you fixed the test plan on that, also, thanks :D

Let's retry :)
Comment 26 Victor Grousset/tuxayo 2024-03-24 22:39:28 UTC
Regardless of me retesting, there are other issues:

Tests don't pass:

t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t ............... 1/7 
    #   Failed test 'no truncation for non non test fields (date) - OK'
    #   at t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t line 171.
    #          got: '1'
    #     expected: '0'

    #   Failed test 'no truncation for non non test fields (date) - OK'
    #   at t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t line 183.
    #          got: '1'
    #     expected: '0'
    # Looks like you failed 2 tests of 9.
t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t ............... 4/7 

Whether on a fresh KTD with patches already applied or a KTD started with main/master and applying the patches + updatedatabase. Same error.

---

Also QA script reports this:

 FAIL	Koha/SearchEngine/Elasticsearch/QueryBuilder.pm
   FAIL	  spelling
		 implicite  ==> implicit, implicitly
   WARN	  tidiness
		The file is less tidy than before (bad/messy lines before: 318, now: 333)

 FAIL	installer/data/mysql/atomicupdate/bug_32707.pl
   FAIL	  file permissions
		File must have the exec flag
   WARN	  tidiness
		The file is less tidy than before (bad/messy lines before: 0, now: 5)

 FAIL	installer/data/mysql/mandatory/sysprefs.sql
   FAIL	  sysprefs_order
		Not blocker: Sysprefs ESPreventAutoTruncate is bad placed (see bug 10610)

 WARN	t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t
   WARN	  tidiness
		The file is less tidy than before (bad/messy lines before: 72, now: 89)
Comment 27 Victor Grousset/tuxayo 2024-03-24 23:14:42 UTC
> 3. Have an analytical record with 773 $w = 1 (in the test data set - biblio 896).

Oh nice! I don't even have to mess around unreliably trying to create analytical records :)

--

Scenario B works :)

I'll retest both after the tests are fixed in case it requires changes in the implementation.
Comment 28 Victor Grousset/tuxayo 2024-03-24 23:22:27 UTC
Just to be sure, when finishing scenario A, one can just revert patches, restart services and start scenario B?
No need to start over from scratch (and reimport & index data), there is only the syspref still hanging in the DB which does no harm.
Comment 29 Janusz Kaczmarek 2024-03-25 15:04:45 UTC
Created attachment 163822 [details] [review]
Bug 32707: Add 'ESPreventAutoTruncate' preference

This patch adds a new 'ESPreventAutoTruncate' preference allowing to define
Elasticsearch search fields that should not be autotruncated when 'QueryAutoTruncate'
is active (e.g. barcode).
Comment 30 Janusz Kaczmarek 2024-03-25 15:04:48 UTC
Created attachment 163823 [details] [review]
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.

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).
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).
Comment 31 Janusz Kaczmarek 2024-03-25 15:04:51 UTC
Created attachment 163824 [details] [review]
Bug 32707: Unit tests

NB in t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t,
I had to modify four existing test by changing Local-number:123456 to
Personal-name:donald -- since Local-number should never be
auto truncated according to the submitted patch.
Comment 32 Janusz Kaczmarek 2024-03-25 15:08:19 UTC
(In reply to Victor Grousset/tuxayo from comment #26)
> Regardless of me retesting, there are other issues:
> 
> Tests don't pass:
> 
> t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t ............... 1/7 
>     #   Failed test 'no truncation for non non test fields (date) - OK'
>     #   at t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t line 171.
>     #          got: '1'
>     #     expected: '0'
> 
>     #   Failed test 'no truncation for non non test fields (date) - OK'
>     #   at t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t line 183.
>     #          got: '1'
>     #     expected: '0'
>     # Looks like you failed 2 tests of 9.
> t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t ............... 4/7 

Updated version provided.  Unfortunately, after modifying the patch in October, I didn't update the tests.  I'm sorry for this.
Comment 33 Victor Grousset/tuxayo 2024-03-26 02:20:34 UTC
Created attachment 163880 [details] [review]
Bug 32707: Unit tests

NB in t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t,
I had to modify four existing test by changing Local-number:123456 to
Personal-name:donald -- since Local-number should never be
auto truncated according to the submitted patch.

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Comment 34 Victor Grousset/tuxayo 2024-03-26 02:20:38 UTC
Created attachment 163881 [details] [review]
Bug 32707: Add 'ESPreventAutoTruncate' preference

This patch adds a new 'ESPreventAutoTruncate' preference allowing to define
Elasticsearch search fields that should not be autotruncated when 'QueryAutoTruncate'
is active (e.g. barcode).

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Comment 35 Victor Grousset/tuxayo 2024-03-26 02:20:41 UTC
Created attachment 163882 [details] [review]
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@tuxayo.net>
Comment 36 Victor Grousset/tuxayo 2024-03-26 02:29:30 UTC
It works :)

---

Thanks for the other fixes.
To spare a QA roundtrip, you can fix the remaining issues:

 WARN	Koha/SearchEngine/Elasticsearch/QueryBuilder.pm
   WARN	  tidiness
		The file is less tidy than before (bad/messy lines before: 318, now: 333)
 WARN	installer/data/mysql/atomicupdate/bug_32707.pl
   WARN	  tidiness
		The file is less tidy than before (bad/messy lines before: 0, now: 5)
 WARN	t/Koha/SearchEngine/Elasticsearch/QueryBuilder.t
   WARN	  tidiness
		The file is less tidy than before (bad/messy lines before: 72, now: 85)

It's a WARN because it's prone to false positives, like at least for autogenerated code or when moving code.
But in this case it seems valid.
Comment 37 Janusz Kaczmarek 2024-03-26 09:53:53 UTC
Created attachment 163892 [details] [review]
Bug 32707: Add 'ESPreventAutoTruncate' preference

This patch adds a new 'ESPreventAutoTruncate' preference allowing to define
Elasticsearch search fields that should not be autotruncated when 'QueryAutoTruncate'
is active (e.g. barcode).

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Comment 38 Janusz Kaczmarek 2024-03-26 09:53:56 UTC
Created attachment 163893 [details] [review]
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@tuxayo.net>
Comment 39 Janusz Kaczmarek 2024-03-26 09:53:59 UTC
Created attachment 163894 [details] [review]
Bug 32707: Unit tests

NB in t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t,
I had to modify four existing test by changing Local-number:123456 to
Personal-name:donald -- since Local-number should never be
auto truncated according to the submitted patch.

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Comment 40 Janusz Kaczmarek 2024-03-26 09:55:25 UTC
(In reply to Victor Grousset/tuxayo from comment #36)
> It's a WARN because it's prone to false positives, like at least for
> autogenerated code or when moving code.
> But in this case it seems valid.

Thank you.  Tidiness corrected.
Comment 41 Nick Clemens 2024-03-29 17:32:54 UTC
Created attachment 164140 [details] [review]
Bug 32707: Add 'ESPreventAutoTruncate' preference

This patch adds a new 'ESPreventAutoTruncate' preference allowing to define
Elasticsearch search fields that should not be autotruncated when 'QueryAutoTruncate'
is active (e.g. barcode).

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 42 Nick Clemens 2024-03-29 17:32:57 UTC
Created attachment 164141 [details] [review]
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@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 43 Nick Clemens 2024-03-29 17:33:00 UTC
Created attachment 164142 [details] [review]
Bug 32707: Unit tests

NB in t/db_dependent/Koha/SearchEngine/Elasticsearch/QueryBuilder.t,
I had to modify four existing test by changing Local-number:123456 to
Personal-name:donald -- since Local-number should never be
auto truncated according to the submitted patch.

Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 44 Katrin Fischer 2024-04-05 15:35:36 UTC
* Say line was missing from database update.
* Link in system preference description was pointing to UseCashRegisters

Fixed in a follow-up.
Comment 45 Katrin Fischer 2024-04-05 15:40:37 UTC
Pushed for 24.05!

Well done everyone, thank you!