April 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 36178] New: Add index for status on message queue table
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36178 Bug ID: 36178 Summary: Add index for status on message queue table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For large libraries, the query to gather pending notices from the message queue can take a very long time. ByWater's Rackpace DBA Mike was kind enough to do some work on this for us and found the issue. He recommends adding a simple index on the status column to fix this issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 8461] Block returns of withdrawn items show as 'not checked out'
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '24

05 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8461 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl Status|Signed Off |Failed QA QA Contact| |m.de.rooy(a)rijksmuseum.nl --- Comment #10 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- if( $issue ){ my $date_due_dt = dt_from_string( $issue->date_due, 'sql' ); $duedate = $date_due_dt->strftime('%Y-%m-%d %H:%M'); $input{borrowernumber} = $issue->borrowernumber; $riborrowernumber{0} = $borrower->{'borrowernumber'}; } $input{duedate} = $duedate; $input{not_returned} = 1; This raises questions. If no issue, you set not_returned? Shouldnt it depend on issue? And some untidiness: WARN circ/returns.pl WARN tidiness The file is less tidy than before (bad/messy lines before: 230, now: 236) -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 36491] New: 500 error on checkout after upgrade
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36491 Bug ID: 36491 Summary: 500 error on checkout after upgrade Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: it.manager(a)hope.edu.kh QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 164268 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164268&action=e… errormessage Hi, just upgraded to 23.11 then ran koha-rebuild-zebra -v -f Since then, I'm getting a 500 error when checking out. I've confirmed homebranch, holdingbranch, and itype are not null (as suggested when searching this issue). I am really at a loss. Error logs are saturated with what I think are unrelated issues. Although, I am admittedly a novice at Koha so I could be very wrong. I've checked opac-error.log, plack-error.log, zebra-output.log. What could I be missing? Thanks in advance -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

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

04 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 9181] Add patron messaging preferences to batch patron modification tool
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9181 --- Comment #7 from Kristi <kkrueger(a)cuyahogalibrary.org> --- This would be really nice. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9181] Add patron messaging preferences to batch patron modification tool
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9181 Kristi <kkrueger(a)cuyahogalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkrueger(a)cuyahogalibrary.or | |g -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36061] New: With IndependentBranches on a non-superlibrarian cannot modify password
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '24

04 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36061 Bug ID: 36061 Summary: With IndependentBranches on a non-superlibrarian cannot modify password Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: marie-luce.laflamme(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the IndependentBranches system preference is turned on, non-superlibrarian staff without the 'view_borrower_infos_from_any_libraries' permission cannot change the patron's passwords, even if those patrons are from the same library. With the current behaviour, it's impossible to reset passwords from the intranet if your library doesn't have a staff member with superlibrarian powers. There are other bugs on similar topic, see: bug 12793 and bug 12599. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

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