September 2023 - Koha-bugs - lists.koha-community.org

[Bug 18341] New: NO-BREAK SPACE is not counted as white space in search queries.
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18341 Bug ID: 18341 Summary: NO-BREAK SPACE is not counted as white space in search queries. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 61648 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=61648&action=ed… CSV file containing titles separated by NO-BREAK SPACE I've transcribed this from a ticket that one of our partners submitted. A librarian noted that she had an Excel spreadsheet of titles she was copying and pasting into Koha to search, and occasionally one of the titles wouldn't come up even though they have the book. ( CSV file containing titles is attached.) She noted if she just typed the title into Koha, it came up w/o a problem. Here's a screenshot of one of the failed searches. Notice the %C2%A0 between the words. That's the UTF-8 code for non-breaking space (see http://www.fileformat.info/info/unicode/char/00a0/index.htm) -- The underlying issue here is that when we paste in a search term containing the unicode NO-BREAK SPACE glyph, this arguably should be treated as white space, and the search should succeed if it matches strings with words separated by other whitespace characters. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 18333] New: Removal of SQL queries from admin/systempreferences.sql
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18333 Bug ID: 18333 Summary: Removal of SQL queries from admin/systempreferences.sql Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This bug report requires the removal of SQL queries from admin/systempreferences.pl to a perl module in C4 or Koha directory. This bug report also requires the writing of POD and unit tests for all new subroutines created in the perl modules to hold these SQL queries. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 18294] New: Keyword searches surrounded by double quotes fail on staff client and OPAC
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18294 Bug ID: 18294 Summary: Keyword searches surrounded by double quotes fail on staff client and OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To replicate: A keyword search for juggling for the complete klutz or a single quoted version of the same: 'juggling for the complete klutz' on https://demo.bywatersolutions.com returns the following result: https://demo.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=… The same search, surrounded by double quotes returns no hits: "juggling for the complete klutz" https://demo.bywatersolutions.com/cgi-bin/koha/opac-search.pl?q=%22juggling… ... RESULTS OF SEARCH FOR 'KW,WRDL: "JUGGLING FOR THE COMPLETE KLUTZ"' No results found! No results found for that in ByWater Library System catalog. Sorry we didn't find what you were looking for [Replicated under 16.11.04.001] -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 16863] New: Quotes around search term cause search failure if QueryAutoTruncate is not enabled.
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16863 Bug ID: 16863 Summary: Quotes around search term cause search failure if QueryAutoTruncate is not enabled. Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The following search will succedd if the system preference 'quryautotruncate' is set to 'always' but will fail if set to 'only if * is added'. http://intranet.bywatersolutions.com/cgi-bin/koha/catalogue/search.pl?q=%22… This causes issues because call number links in the search results are quoted. To replicate: 1/ Set quryautotruncate to 'only if * is added'. 2/ Run a keyword search, with quotes around the title, e.g. "The Hobbit" Seearch will fail 3/ Set quryautotruncate to 'always' 4/ Re-run the same search. It will succeed. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 18252] New: Move C4::Items code to the Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18252 Bug ID: 18252 Summary: Move C4::Items code to the Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 18225] New: Return date to be same as issue date after holiday closed period
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18225 Bug ID: 18225 Summary: Return date to be same as issue date after holiday closed period Change sponsored?: --- Product: Koha Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.stone(a)wiltshire.ac.uk QA Contact: testopia(a)bugs.koha-community.org Request for return date to be same as issue date after holiday closed period. Currently having to manually change each Hard Due Date via Circulation and Fine Rules for every variation of Patron Category and item type with 21 day loans and 7 day loans before holiday closed period. Then return to "none defined" manually. Due to having students that do not attend every day of the week, we need return dates to be on the same day of the week as the day they are issued. This works until we have a closed period when the return date automatically goes to the first day that we are open. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 18216] New: Apache2.4 403 errors for Gitified or git clone installs
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18216 Bug ID: 18216 Summary: Apache2.4 403 errors for Gitified or git clone installs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Fixes this install step for dev installs: https://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#403_errors_f… --SNIP-- 403 errors for Gitified or git clone installs In Ubuntu 14.04 you may discover that your gitified install returns 403 errors - this is because of the changes to Apache directory security. A possible fix includes adding the following stanza to apache2.conf (could be added in the virtualhost, or in one of the koha-shared*.conf files as well): <Directory /home/my-user/koha-src/koha/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory> --SNAP-- -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 18202] New: Define profiles for Z39.50 server targets
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18202 Bug ID: 18202 Summary: Define profiles for Z39.50 server targets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Different Z39.50 servers support different use attributes using different profiles. NorZIG: http://www.norzig.no/profiles/profile2.1.html Libraries Australia (LA): http://www.nla.gov.au/librariesaustralia/services/search/z3950/ Library of Congress (LOC): https://www.loc.gov/z3950/lcserver.html More profiles: https://www.loc.gov/z3950/agency/profiles/profiles.html In the case of Libraries Australia and Library of Congress, the profiles are different between bibliographic databases and authority databases, and this can be traced back to differences in the functional areas of the Bath profile: http://web.archive.org/web/20080218122658/http://www.collectionscanada.gc.c… For instance, Libraries Australia claims to support "Functional Area D (Authority Record Search & Retrieval) to Level 1" http://web.archive.org/web/20080219085710/http://www.collectionscanada.gc.c… It doesn't appear to in reality as it doesn't support use attribute 1002 (while the Library of Congress does support this use attribute). The Library of Congress appears to be more in line with Functional Area D (Authority Record Search & Retrieval) to Level 2: http://web.archive.org/web/20080219085716/http://www.collectionscanada.gc.c… It doesn't look like LOC perfectly adheres to Level 2, but I'd say it does up to 99.99%. It also supports a extra attributes belonging to local indexes. Anyway, here's the problem: LOC use attributes 1,2, and 3, but LA does not support these attributes. On the other hand, LA supports 1003, 1004, 1005, and 1006, but LOC does not. LOC supports 1002, but LA does not. We need to be able to define profiles on a server by server basis. In fact, this is even recommended by Libraries Australia: "Step 4. Configure your Bib-1 Search Attributes (if required):". -- I don't think it would be that difficult to define profiles. We'd have a table with id, profile name, a name/index/description column, and a use attribute column. Then we could add a foreign key to z3950servers to specify the profile. We'd need to do a different query for each server target but that would be easy enough on its own. The difficulty may lie in what to do about the Z39.50 search form. Not all "names" would be supported by all targets. Bug 18096 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18096) also mentions some local attributes. We don't have a way of specifying those in the search form at the moment, and obviously those local attributes would be local to that particular server. I suppose we could dynamically create the search form... but again not all names will correspond to all servers. I suppose we could just add that caveat. We could also be better with our presentation of results. If we get an error code of unsupported use attribute from a target server, we could surface that to users. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 18197] New: Make borrowers-force-messaging-defaults a bit more standard
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18197 Bug ID: 18197 Summary: Make borrowers-force-messaging-defaults a bit more standard Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Possible tasks to do: - Make it .pl - give it better help documentation - make sure it's presence is noted in the manual - make it so that optionally, if a borrower has preferences set that don't match the default, that borrower is skipped for re-setting (as they have likely set their preferences). For another time, but just noting it: put a function that does this into the web interface for superlibrarians. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 18196] New: Holds Queue table should link to Holds table by reserve_id
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '23

10 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18196 Bug ID: 18196 Summary: Holds Queue table should link to Holds table by reserve_id Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Now that the 'reserves' table has an id column, it would be nice to link the tmp_holdsqueue table to it using reserves_id as a foreign key. Furthermore, we could require the tmp+holdsqueue column to be unique, as we can only have a single line in tmp_holdsqueue for any given rserve_id. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1