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

[Bug 32502] New: Getting patrons/{patron_id} via REST API requires edit_borrowers permission
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32502 Bug ID: 32502 Summary: Getting patrons/{patron_id} via REST API requires edit_borrowers permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi CC: tomascohen(a)gmail.com Staff without edit_borrowers permission can see patrons info in detail.pl or returns.pl, but not via REST API call GET patrons/{patron_id}. We should use permission view_borrower_infos_from_any_libraries here instead of edit_borrowers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 27768] New: Saving an item with an invalid dateaccessioned or replacementpricedate throws
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27768 Bug ID: 27768 Summary: Saving an item with an invalid dateaccessioned or replacementpricedate throws Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Steps to reproduce: 1. Edit any item, change either the "d - Date acquired" or "w - Price effective from" to anything not-a-date (I like 24.99, due to mispasting Replacement price into Price effective from 2. Save the record Actual result: Invalid value passed, items.replacementpricedate=2 expected type is date at /usr/share/perl5/Exception/Class/Base.pm line 88 You can hit Back in the browser to go back and fix it, assuming you know what an items.replacementpricedate is or have an English speaker handy to tell you it's the Дата, для якої чинна ціна заміни. Expected result: Human readable message in a popup or in the page itself, giving the name of the field in the editor, rather than the name of the field in the database -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 30373] New: Rewrite UNIMARC installer data to YAML
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30373 Bug ID: 30373 Summary: Rewrite UNIMARC installer data to YAML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr A complete rewrite (and update) of UNIMARC installation files from SQL to YAML is needed to allow the translation of its frameworks. Both bibliographic and authorities frameworks have been updated up to 2019. References: * Bibliographic: https://www.ifla.org/g/unimarc-rg/unimarc-bibliographic-3rd-edition-with-up… * Authorities: https://www.ifla.org/g/unimarc-rg/unimarc-authorities-3rd-edition-with-upda… Some patches are compressed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 80

[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 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 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

[Bug 30887] New: Gravestone page for deleted authorities or biblios
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30887 Bug ID: 30887 Summary: Gravestone page for deleted authorities or biblios Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org When you assign a persistent identifier to your Koha record (auth or biblio) and you delete that record at some point in time, it would be good to resolve the persistent identifier to a gravestone/tombstone page that at least tells that the record has been deleted, perhaps even more. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 23609] New: Tie patron gender to an authorized value
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23609 Bug ID: 23609 Summary: Tie patron gender to an authorized value Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the interest of allowing greater flexibility, it'd be great to have gender tied to an authorized value so libraries can edit/add/delete options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12