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

[Bug 21825] New: UNIMARC Authority subfields missing 'u'
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '24

13 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21825 Bug ID: 21825 Summary: UNIMARC Authority subfields missing 'u' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Whilst QAing bug 19365 I spotted that the subfields string contains all of the alphabet except for 'u' and I wondered whether this was deliberate or a mistake? When asking the question on IRC it sounded as though subfield 'u' may well be used but we wanted to defer to some more expert cataloguers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 21773] New: Increase minimum MockModule version (and switch to ->redefine)
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '24

13 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21773 Bug ID: 21773 Summary: Increase minimum MockModule version (and switch to ->redefine) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Our minimum version of MockModule is very low and as such doesn't support the safer 'redefined' method. If at all possible, it would be great to up this module version and replace our calls to mock with calls to redefine so we can catch when methods are renamed or removed. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 21386] New: Receive shipment from vendor X: Items expected is never more than 0
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '24

13 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21386 Bug ID: 21386 Summary: Receive shipment from vendor X: Items expected is never more than 0 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org I'm not sure what the point of this field is on this page in the summary of invoices table, but I can never get it to show anything other than 0. Do we know what it was intended to show and if it's still relevant? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 21069] New: Koha::Patron->generate_userid use encourages a race condition
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '24

13 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21069 Bug ID: 21069 Summary: Koha::Patron->generate_userid use encourages a race condition 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: 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 We're using ->generate_userid followed later down a script by ->store in a number of places. This is a race condition whereby we could inadvertantly end up with duplicate userid's on the system. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22103] New: ILL: Tests for migrate
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22103 Bug ID: 22103 Summary: ILL: Tests for migrate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Target Milestone: --- We decided to PQA on bug 20640 so that QA could continue on the ILL tree.. but, I spotted right at the last moment that I've managed to miss the tests somehow.. I'll be submitting them here shortly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30362] New: GetSoonestRenewDate is technically wrong when NoRenewalBeforePrecision set to date soonest renewal is today
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30362 Bug ID: 30362 Summary: GetSoonestRenewDate is technically wrong when NoRenewalBeforePrecision set to date soonest renewal is today Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial 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 In the code: 3309 if ( C4::Context->preference('NoRenewalBeforePrecision') eq 'date' 3310 and $issuing_rule->{lengthunit} eq 'days' ) 3311 { 3312 $soonestrenewal->truncate( to => 'day' ); 3313 } 3314 return $soonestrenewal if $now < $soonestrenewal; We truncate soonest renewal, so when it matches todays date line 3314 compares Today at 00:00:00 to Today at (time renewal checked) So we don't return soonest renewal, but fall back to $now - which does allow renewal, but is not technically correct -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 16117] New: Feature request: Log borrower cardnumbers and item barcodes which are not valid
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16117 Bug ID: 16117 Summary: Feature request: Log borrower cardnumbers and item barcodes which are not valid Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On any circ screen where a barcode could be scanned (circ.pl, checkin.pl, checkout and return boxes), we should have the option of logging failed barcode scans, for the purpose of trouble-shooting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 17337] New: waitingreserves.pl should trigger transfers as well as holds
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '24

11 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17337 Bug ID: 17337 Summary: waitingreserves.pl should trigger transfers as well as holds Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 17010 addresses triggering the next hold when a hold is cancelled, but transfers should also be triggered. Currently in 3.22.8 nothing happens. It is unclear if 17010 addresses transfers as well. Also, in 3.18 local holds were spotty when holds were triggered. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 26978] New: Add item type criteria to batch extend due date tool
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26978 Bug ID: 26978 Summary: Add item type criteria to batch extend due date tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In the Change due date plugin by inLibro, there is a possibility of choosing specific item types to extend due dates. I think the original purpose of the batch extend due date tool was for COVID and the purpose was to extend everything regardless, as the libraries were closed. However, it would be nice if we could discontinue de plugin in favour of the native tool. But that would require that the native tool have all the options that the plugin has. https://inlibro.com/en/changeduedate-instructions/ One example of use case would be where a school would want to extend loans for textbooks, because the semester was extended, but not the other types of items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 29930] New: Auth with LDAP: Update tag leads to unwanted updates
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29930 Bug ID: 29930 Summary: Auth with LDAP: Update tag leads to unwanted updates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: janik.hilser(a)systemli.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I have observed that as soon as the update tag is set to true in koha-config.xml, the cardnumber is also updated on every login, even if it is not in the mappings. After a login the cardnumber is equal to the userId, but according to log entries it is empty in between. I could see this in the log entry that is generated in line 214 of the Auth_with_ldap.pm. Maybe line 262 of the same file has something to do with it? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42