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

[Bug 32332] New: bulkmarcimport.pl -insert fails to add MARC field 999
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32332 Bug ID: 32332 Summary: bulkmarcimport.pl -insert fails to add MARC field 999 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We have several libraries that have problems with their batch imports/updates from external sources after upgrading to 22.05.06. The problem is that records that are imported and/or updated via bulkmarcimport.pl do not get a 999 field, with the biblionumber in $c and $d. No 999 field is added at all. To reproduce in koha-testing-docker: - Edit koha/t/db_dependent/Record/testrecords/marcxml_utf8.xml and remove the 952 field (otherwise Koha will complain about an undefined branchcode) - Import that file: $ sudo koha-shell -c "perl koha/misc/migration_tools/bulkmarcimport.pl -b -v -m=MARCXML -match=Control-number,001 -insert -l=/tmp/import.log -file koha/t/db_dependent/Record/testrecords/marcxml_utf8.xml" kohadev - Check the result: $ sudo koha-mysql kohadev MariaDB [koha_kohadev]> SELECT biblionumber, ExtractValue(metadata, 'count(//datafield[@tag="999"])') AS count999 FROM biblio_metadata HAVING count999 = 0; This should give output like this: +--------------+----------+ | biblionumber | count999 | +--------------+----------+ | 439 | 0 | +--------------+----------+ 1 row in set (0.013 sec) ...meaning biblionumber 439 does not have a 999 field. - Updating the same record: $ sudo koha-shell -c "perl koha/misc/migration_tools/bulkmarcimport.pl -b -v -m=MARCXML -match=Control-number,001 -update -l=/tmp/import.log -file koha/t/db_dependent/Record/testrecords/marcxml_utf8.xml" kohadev ...seems to add the 999 and make the problem go away: $ sudo koha-mysql kohadev MariaDB [koha_kohadev]> SELECT biblionumber, ExtractValue(metadata, 'count(//datafield[@tag="999"])') AS count999 FROM biblio_metadata HAVING count999 = 0; Empty set (0.009 sec) BUT on live servers (running 22.05.06, not master like in ktd) it looks like updating a record via bulkmarcimport.pl can cause an existing record to loose its 999 field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 34826] New: Circulation rules edit row select elements don't always update when selecting new row for editing
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34826 Bug ID: 34826 Summary: Circulation rules edit row select elements don't always update when selecting new row for editing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: mikko.liimatainen(a)turku.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When editing circulation and fine rules selecting another row for editing without saving first can cause an issue where select elements on edit row don't update properly. This seems to be caused by adding additional selected values for select options each time different line is selected for editing. For example if you select each item type rule for editing you can have all item types selected on edit row select element after which that element doesn't update at all anymore when selecting new row for editing. I think clearing selected values from these select options each time when selecting new row for editing before adding selected value for the right option should fix the issue. At least there would no longer be conflict on which option value is actually selected. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 21676] New: Advanced editor - Rancor - complains on empty line at end
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21676 Bug ID: 21676 Summary: Advanced editor - Rancor - complains on empty line at end Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Minor usability irritation: Rancor complains about "Invalid tag number" on a completely empty line. You tend to automatically press enter at the end of a field, meaning you may have an empty line at the end of the record... and then Rancor complains when trying to save. Should instead just silently discard the empty line at the end before saving. Same complaint happens if there's an empty line in the middle, but I'm not sure if that should be silently discarded. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30109] New: Wrong interface in logs when renewing patron
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30109 Bug ID: 30109 Summary: Wrong interface in logs when renewing patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I have not been able to recreate this in my testing environment, however, I can find evidence of the problem in many production environments. When renewing a patron the interface recorded in action logs is often 'api' SELECT * FROM action_logs WHERE module='MEMBERS' AND action="RENEW" AND interface='api'; The specific log is from Koha::Patron->renew_account This is only called in members/setstatus.pl setstatus uses 'checkauth' rather than other routines for verifying logged in patron, and it seems that the interface must not be set for Context in that call -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 20203] New: Add info about contributing to koha-community.org/documentation/
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20203 Bug ID: 20203 Summary: Add info about contributing to koha-community.org/documentation/ Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Websites, Mailing Lists, etc Assignee: wizzyrea(a)gmail.com Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org It might be nice if the page at https://koha-community.org/documentation/ said something about how to contribute to the documentation, or linked to such info published elsewhere. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 34676] New: Add an option for holds queue to only map unassigned requests to items
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34676 Bug ID: 34676 Summary: Add an option for holds queue to only map unassigned requests to items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When using the real time holds queue new requests rebuild the entire holds queue - this can mean libraries go to find a book on a shelf, only to find the queue has changed and another item has filled the request in the meantime. Similarly, when not using the real time holds queue, some libraries will limit the cron to running once a day to avoid ever changing holds lists. It would be nice to have an option for both methods that would limit the queue to filling new holds without deleting the current queue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 23015] New: Create a "GetPickupLocation" endpoint for the ILS-DI Service
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23015 Bug ID: 23015 Summary: Create a "GetPickupLocation" endpoint for the ILS-DI Service Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- That endpoint may take 2 parameters: - a borrowernumber - and a biblio or item number And it would return a list of available pickup location given a user and a biblio or item. On success would return the following example : <?xml version="1.0" encoding="UTF-8"?> <pickup_locations> <pickup_location> <pickup_location_label>First library</pickup_location_label> <pickup_location_id>1</pickup_location_id> </pickup_location> <pickup_location> <pickup_location_label>Second library</pickup_location_label> <pickup_location_id>2</pickup_location_id> </pickup_location> </pickup_locations> On error : - PatronNotFound in case borrowernumber is not found - RecordNotFound in case Biblio doesn't exist - ItemNotFound in case item doesn't exist -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 35391] New: In new order empty first item type is selected
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '24

03 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35391 Bug ID: 35391 Summary: In new order empty first item type is selected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When creating a new order from suggestion or new empty record, the first item type is selected. There should be an empty value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 25990] New: `WhenLostChargeReplacementFee` and `WhenLostForgiveFine` preferences should be moved into circulation rules to be consistent with `RefundLostOnReturn` rules
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '24

03 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25990 Bug ID: 25990 Summary: `WhenLostChargeReplacementFee` and `WhenLostForgiveFine` preferences should be moved into circulation rules to be consistent with `RefundLostOnReturn` rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently there is an inconsistency with the level at which `WhenLostChargeReplacementFee` and `WhenLostForgiveFine` can be set when compared to the complimentary `RefundLostOnReturn` rule. For consortial installations, all these rules should apply at the same level, be that system or branch level.. I propose to move the two 'system' level preferences into 'branch' level by migrating them into the circulation rules area. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 35591] New: bulkmarcimport.pl overwrites data if controlnumber eq authid
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '24

03 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35591 Bug ID: 35591 Summary: bulkmarcimport.pl overwrites data if controlnumber eq authid Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org We had a lot of auth_header (~700.000). Then we decided to import a lot more (10.000.000). We used --update together with a match-rule (based on 024) to prevent duplicates. Which all worked well. Until... We discovered that ~30k of our old auths where overwritten with "random" data (some other auths). What used to be "Graz" was now "Centro Editoriale Valtortiano". After a bit of panic we were able to restore our old auths from a backup. But what happend? The problem is that eg "Graz" had authid=777317. But "Valtortiano" has 001=00777317X. If you squint a bit (and ignore the leading 0s and the X at the end) that's the same number! And it seems that C4::AuthoritiesMarc::GuessAuthId($record) returns the value of 001, which somehow causes the confusion. I'm not entirely sure yet, where the X is stripped, but the effect is that auth-record 777317 is overwritten. An easy fix would be to add a new command line param to bulkmarcimport to either disable the call to GuessAuthId (which keeps with backwards compat, but makes it easy for other people to also run into this problem); or to only call GuessAuthId if the new param is set (saver, but changes behaviour) If you agree that this is a problem, I can prepare a patch. If we did something stupid, please enlighten us! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15