December 2018 - Koha-bugs - lists.koha-community.org

[Bug 21952] New: Renewal should not set an earlier new due date
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '21

30 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21952 Bug ID: 21952 Summary: Renewal should not set an earlier new due date Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In checkouts table, one can select several rows, define a new due date and renew. The issue is that you can set a new due date that is earlier than actual due date. This makes no sens for a renewal. It should be checked for each checkout, maybe like on hold check. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 20501] New: Unhighlight in search results when the search terms contain the same word twice removes the word
by bugzilla-daemon＠bugs.koha-community.org 26 Nov '21

26 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20501 Bug ID: 20501 Summary: Unhighlight in search results when the search terms contain the same word twice removes the word Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org If you search in the staff client for the keyword apple, you can then unhighlight and hightlight again over and over without harm, but if you search for the keyword apple apple (or any other repeated word, the search that showed it to me was the word A in A giraffe and a half), when you click unhighlight the first instance of the repeated word is completely removed from each search result, and if you click highlight, and then click unhighlight again, the next instance will be removed each time you highlight/unhighlight. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 17775] New: blocker of bug 7172
by bugzilla-daemon＠bugs.koha-community.org 24 Nov '21

24 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17775 Bug ID: 17775 Summary: blocker of bug 7172 Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: mnashbat(a)alfaisal.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Koha & ldap authentication fail authenticating new users when enabling plack, it works fine only if plack is desabled. Ldap authentication works fine with old registered users. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 19444] New: Automatic renewal script should not auto-renew if a patron' s record has expired
by bugzilla-daemon＠bugs.koha-community.org 23 Nov '21

23 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19444 Bug ID: 19444 Summary: Automatic renewal script should not auto-renew if a patron's record has expired 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: janet.mcgowan(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently with the automatic_renewals.pl script, materials are still auto-renewed even if the patron's account has expired. The automatic renewals script has error conditions which prevent automatic renewals in these circumstances: $error eq 'too_many' or $error eq 'on_reserve' or $error eq 'restriction' or $error eq 'overdue' or $error eq 'auto_too_late' or $error eq 'auto_too_much_oweing' or $error eq 'auto_too_soon The error conditions should take into account the expiry date of borrower and not auto renew if the borrower's account has expired. For example adding a new error code such as 'borrower_expired' - or whatever convention achieves this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 17979] New: Fatal error when searching from addbooks.pl due to ISBN flaw
by bugzilla-daemon＠bugs.koha-community.org 23 Nov '21

23 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17979 Bug ID: 17979 Summary: Fatal error when searching from addbooks.pl due to ISBN flaw Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you're doing a "Cataloging Search" from /cgi-bin/koha/cataloguing/addbooks.pl, and you type in "1st to die", you'll see the following: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 5 at /<koha>/lib/C4/Breeding.pm line 107 The reason is that the string is 10 characters long and contains a digit, so Koha thinks it's an ISBN. But when it tries to normalize it, it fails, and instead Koha generates no data for the WHERE clause and then the SQL statement fails because it contains a WHERE without the actual clause. The code: if ($query) { # fill isbn or title, depending on what has been entered #u must do check on isbn because u can find number in beginning of title #check is on isbn legnth 13 for new isbn and 10 for old isbn my ( $title, $isbn ); if ($query=~/\d/) { my $clean_query = $query; $clean_query =~ s/-//g; # remove hyphens my $querylength = length $clean_query; if ( $querylength == 13 || $querylength == 10 ) { $isbn = $query; } } if (!$isbn) { $title = $query; } ( $countbr, @resultsbr ) = BreedingSearch( $title, $isbn ); } -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 17423] New: patronimage.pl permission is too restrictive
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '21

22 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17423 Bug ID: 17423 Summary: patronimage.pl permission is too restrictive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 14566 added the permission "borrowers" on patronimage.pl. This perm is too restrictive because circulation pages also uses this page. I propose to simply use "catalogue" perm. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 18967] New: Acquisitions Receipt Summary Search Filter
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '21

22 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18967 Bug ID: 18967 Summary: Acquisitions Receipt Summary Search Filter Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 65152 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=65152&action=ed… Receipt Summary Search Filter on First Invoice When receiving items in the Acquisitions module the search filter on the receipt summary page does not automatically clear out and ends up filtering-out items on all future invoices that are opened. Because the search term persists -even after navigating away from the page, restarting the PC, or clearing the browser cache- and is easy to overlook it can lead to lots of confusion. To replicate: 1.) Go to the Acquisitions module and select an open invoice. 2.) Click 'Go to receipt page.' 3.) Enter random text into the 'Pending orders' search filter 4.) Open a different invoice, restart the PC, log-out/in, shut the computer off for a week, whatever 5.) Return to the Receipt summary page on any invoice. The term remains in the filter. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 19036] New: Numer payment receipts / payment slips
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '21

22 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19036 Bug ID: 19036 Summary: Numer payment receipts / payment slips Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In some areas it's required to sequentially number payment slips / receipts. At the moment this is not easily possible in Koha, as we don't have a sequential internal number for the payments, but will hopefully be possible in some point in the future with the work on the Accounts module. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 90

[Bug 21105] New: oai.pl returns invalid earliestDatestamp
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '21

20 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21105 Bug ID: 21105 Summary: oai.pl returns invalid earliestDatestamp Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 21102 From: https://www.openarchives.org/OAI/openarchivesprotocol.html#DatestampsRespon… Dates should be YYYY-MM-DDThh:mm:ssZ curl -s "baseURL?verb=Identify" | xmllint --format - | grep Date responseDate -> 2018-07-23T18:34:15Z : OK earliestDatestamp -> 2010-09-30 16:04:37 : FAIL Originally deteced with official validator: https://www.openarchives.org/Register/ValidateSite Related: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17785#c13 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21102 [Bug 21102] OAI-PMH specification conformance [UMBRELLA] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 16885] New: koha-stop-zebra should be more sure of stopping zebrasrv
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '21

18 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16885 Bug ID: 16885 Summary: koha-stop-zebra should be more sure of stopping zebrasrv Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net The koha-stop-zebra command can finish without ensuring that zebrasrv is actually stopped. In particular, if there is an active query running when daemon --stop is run, the following state of affairs will occur until the query finishes or times out: - the child zebrasrv processing the query continues to run - the parent zebrasrv process becomes a zombie - the daemon(1) process continues to run -- and doesn't delete the lock file until the children go away. This is particularly problematic when a koha-stop-zebra is followed by a koha-start-zebra in quick succession, as happens during a logrotate. This is because while zebrasrv is in the half-stopped, half-started stop, the lock file still exists... and koha-start-zebra will see it and believe that zebrasrv is still running. When the query holding the child zebrasrv process finishes, the instance is left with no running Zebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25