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

[Bug 37718] New: MarcFieldsToOrder cannot process repeated fields
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37718 Bug ID: 37718 Summary: MarcFieldsToOrder cannot process repeated fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Before bug 35026 the MarcFieldsToOrder system preference would simply take the first value from a field if there were multiple - it now throws an error when trying to pull price from 020$c if there are two isbns. To test: 1 - Find a marc file with 2 isbn fields, each including price 2 - Add to MarcFieldsToOrder: price: 020$c 3 - Stage file 4 - Add to basket from staged file 5 - Error: Invalid number of fields detected on field 020, please check this file at /kohadevbox/koha/Koha/MarcOrder.pm line 156 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 34312] New: Advanced Editor - Rancor - Restore UNIMARC encoding support
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34312 Bug ID: 34312 Summary: Advanced Editor - Rancor - Restore UNIMARC encoding support Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: synapse.ova(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Starting from at least version 22.11 opening UNIMARC bib records in advanced cataloging editor leaves only latin symbols and removes all other symbols (cyrillic, for example). At the same time, the record is opened normally in basic editor. Examples of errors of intranet-error.log: [Sun Jul 16 18:45:03.590680 2023] [cgi:error] [pid 11663] [client 172.93.185.137:42482] AH01215: Wide character (U+43E) in substitution (s///) at /usr/lib/x86_64-linux-gnu/perl5/5.36/Template/Filters.pm line 62.: /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl, referer: https://koha.tci.org.ua/cgi-bin/koha/cataloguing/editor.pl [Sun Jul 16 18:45:24.883138 2023] [cgi:error] [pid 11738] [client 172.93.185.137:42592] AH01215: Wide character in warn at /usr/share/perl5/MARC/Charset.pm line 308.: /usr/share/koha/intranet/cgi-bin/svc/bib, referer: https://koha.tci.org.ua/cgi-bin/koha/cataloguing/editor.pl [Sun Jul 16 18:45:24.883965 2023] [cgi:error] [pid 11738] [client 172.93.185.137:42592] AH01215: no mapping found for [0x425] at position 0 in \xd0\xa5\xd0\xb5\xd1\x80\xd1\x81\xd0\xbe\xd0\xbd g0=ASCII_DEFAULT g1=EXTENDED_LATIN at /usr/share/perl5/MARC/Charset.pm line 308.: /usr/share/koha/intranet/cgi-bin/svc/bib, referer: https://koha.tci.org.ua/cgi-bin/koha/cataloguing/editor.pl [Sun Jul 16 18:45:24.883999 2023] [cgi:error] [pid 11738] [client 172.93.185.137:42592] AH01215: Wide character in warn at /usr/share/perl5/MARC/Charset.pm line 308.: /usr/share/koha/intranet/cgi-bin/svc/bib, referer: https://koha.tci.org.ua/cgi-bin/koha/cataloguing/editor.pl Even though the record is in unicode, it is obvious that encoding used by advanced editor is wrong. Code analysis shows that function marc8_to_utf8 is used, treating all utf8 symbols as marc8, therefore removing non ASCII characters. Looks like chosing of encoding is hardcoded for MARC21 (checked in record leader) and now is not compatible with UNIMARC (encoding is put in field 100). Encoding in MARC21 is stored in leader with character 09: " " (blank space) means coding is MARC-8 and "a" is UCS/Unicode (https://www.loc.gov/marc/bibliographic/bdleader.html) The same leader character 09 in UNIMARC in first editions should be blank (which is the case for most of our bib records). Since 2012 (https://cdn.ifla.org/wp-content/uploads/files/assets/uca/unimarc_updates/BI…) this character is for Type of control: " " (blank space) means no specific type of control applies to the item being described and "a" is for Archival control. Since 2016 (https://cdn.ifla.org/wp-content/uploads/files/assets/uca/unimarc_updates/BI…) "m" is added for Museum control. Therefore it is better to use the same code for discovering encoding as in basic editor. == Steps to reproduce the problem == The following steps are for UNIMARC Koha even though most likely the result would be the same on MARC21 as well. 1) Preliminary step 1. Check that advanced cataloging editor is enabled: Administration → System preferences → EnableAdvancedCatalogingEditor 2) Preliminary step 2. Check that bibliographical framework shows leader (000) and allows to edit it. 3) Open or prepare a bib record with non ASCII characters. For example, add αβγδεζηθικλμνξοπρστυφχψωæäåąßćęłńóśøöüźżабвгдежзийклмнопрстуфхцчшщьыъэюяёєїґўі’ to field 200$a or in other subfield. 4) Edit leader so that character 09 is blank. For example, paste " nam0 4500" (without quotation marks) 5) Switch to advanced editor. Settings → Switch to advanced editor. 6) Observe non-ASCII characters are gone The problem may be temporarily solved by user by changing character 09 in leader (field 000) to "a". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 37923] New: Overdue Notice texts based on renewals
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37923 Bug ID: 37923 Summary: Overdue Notice texts based on renewals Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.evans(a)ukhsa.gov.uk QA Contact: testopia(a)bugs.koha-community.org We would like to be able to specify different overdue notice texts depending whether the item on loan can be renewed. If the item has reached the maximum number of renewals or is otherwise not renewable we would want to use a different notice text, usually explaining that the item needs to be returned to the library. At the moment the notice text we use has instructions on how to renew items then a section on what to do if the item cannot be renewed which is making the notice longer than we would like and all items are listed in the same list. So if we can specify separate notices depending if the item can be renewed we can send out 2 emails with clear instructions relevant to the item listed in that notice which can be much shorter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37819] New: Koha could auto-update due dates if patron dateexpiry is updated to before current item due date
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37819 Bug ID: 37819 Summary: Koha could auto-update due dates if patron dateexpiry is updated to before current item due date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris.rowlands6(a)nhs.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is currently achieved by library staff renewing the patron's items with the ReturnBeforeExpiry setting set to "Require". A couple of libraries in our consortium have suggested it would be more convenient if this was done automatically when saving a patron record after editing the dateexpiry field. I expect for professional/health libraries where users leave their posts at quite short notice would find this useful. I'm imagining a couple of solutions; maybe a checkbox in the patron edit screen under date expiry saying something like "Update due dates" or an admin setting sitting with ReturnBeforeExpiry that checks and updates due dates if the patron's dateexpiry is edited. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 37921] New: add note to accountline when using writeoff_debts.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37921 Bug ID: 37921 Summary: add note to accountline when using writeoff_debts.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 27049 It'd be great if the writeoff_debts cron would allow the definition of a note to be added to all the writeoffs it performs. One could set a --note flag and supply a string: --note "Writeoff by cron" or what have you. As is, there's nothing on the accountline that clearly shows why or how this writeoff happened, one must intuit that the cron was involved via the timestamp and lack of recorded librarian. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27049 [Bug 27049] Add a script to bulk writeoff debts -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 33802] New: On OPAC authority detail page, usage count in erroneous
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33802 Bug ID: 33802 Summary: On OPAC authority detail page, usage count in erroneous Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: frederic(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org On OPAC opac-authoritiesdetail.pl page, usage count is wrong. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 37508] SQL reports should not show patron password hash if queried
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37508 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37919 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37919 [Bug 37919] Unable to report on MFA-enabled users -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37909] New: Installing Plugin from search box is not working
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37909 Bug ID: 37909 Summary: Installing Plugin from search box is not working Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jesse(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is happening in 24.05 Use the “search for plugins” field to search the repos for a plugin from the plugin adminstration in Koha, and click install. - nothing seems to happens - -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 30897] New: Gracefully reload Koha after plugin install/upgrade
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30897 Bug ID: 30897 Summary: Gracefully reload Koha after plugin install/upgrade Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org When a plugin is installed/upgraded, it would be good to send a SIGHUP to the Starman master, so that Koha will gracefully restart itself. As Kyle noted on the listserv, it is especially useful for plugins that add API routes, since the API can't use those until Starman workers are restarted. By doing a graceful restart, no active HTTP requests are interrupted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 36960] New: Apply Multiple MARC Modification Templates when staging MARC records
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36960 Bug ID: 36960 Summary: Apply Multiple MARC Modification Templates when staging MARC records Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mnero(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When staging MARC records, we are only able to select one MARC Modification Template. It would be useful to be able to apply more than one at a time. Use case: when staging vendor loads, I have 3 different fields to update depending on the vendor, but the combinations vary. Currently, I have to create a template for each combination, but it would be preferable to be able to choose the template for each field instead of one of every combination of the following: MARC Tag A - 2 options MARC Tag B - 3 options MARC Tag C - 15+ options A1 + B1 + C1 A1 + B1 + C2 A1 + B1 + C3 A1 + B2 + C1 A1 + B2 + C2 A1 + B2 + C3 A1 + B3 + C1 A1 + B3 + C2 A1 + B3 + C3 etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5