March 2025 - Koha-bugs - lists.koha-community.org

[Bug 37542] New: Patron search is incorrectly parsing entries as dates and fetching the wrong patron if dateofbirth in search fields
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37542 Bug ID: 37542 Summary: Patron search is incorrectly parsing entries as dates and fetching the wrong patron if dateofbirth in search fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com When parsing patron search we try to convert the input into a date for searching against dateofbirth if included in defaultpatronsearchfields This can lead to odd values being converted to incorrect dates. To recreate" 1 - Create a patron with dateofbirth 1994-07-27 2 - Add dateofbirth to DefaultPatronSearchFields 3 - In patron or checkout search, type a cardnumber like '2908800092528' 4 - Note the patron with that birth date is found in autocomplete 5 - Open the browser console (F12) 6 - In the network tab, find the last request (or just remove and add a digit) 7 - Copy the URL from that request and paste into a text editor 8 - Search for 'dateofbirth' 9 - See that the entry has been converted to 1994-07-27 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 37499] New: Remove global variables from addbiblio.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37499 Bug ID: 37499 Summary: Remove global variables from addbiblio.pl Change sponsored?: --- Product: Koha Version: Main 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: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 37429 addbiblio.pl contains a number of global variables. Some if not all of them are state variables that have no business being globals. We should refactor to scope these variables appropriately. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37429 [Bug 37429] Can't edit biblio records anymore (empty form) in 24.05 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 37429] New: Can't edit biblio records anymore (empty form) in 24.05
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37429 Bug ID: 37429 Summary: Can't edit biblio records anymore (empty form) in 24.05 Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)zefanjas.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl While cataloging new books the edit / add biblio form is sometimes empty. This happens also when I want to edit an existing biblio or import one via Z.39.50. Sometime I can add 5-10 new items before it happens, sometimes it happens after every new record. The only "fix" right now for me is to do a `service koha-common restart`. The log files don't show any error. To reproduce the issue: 1. Open an existing biblio (detail.pl) 2. Click "Edit record" 3. Change the framework (no need to change any details) 4. Change the framework back to the original one (no need to save anything) 5. Go back to the biblio overview page (detail.pl) 6. Click "Edit record" again → mask / form is empty -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 37892] New: Patron category 'can be a guarantee' means that same category cannot be a guarantor
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37892 Bug ID: 37892 Summary: Patron category 'can be a guarantee' means that same category cannot be a guarantor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Bug 12133 changed the way that these categories work. Before hand, a single category could be set up, and two patrons in that category could be set to have a guarantor/guarantee relationship. In upgrades, we are seeing that if this relationship is preexisting, patrons are unable to return items as we throw an exception: "Child cannot be a guarantor" I understand preventing the same patron from being a guarantor and a guarantee, however, is it correct that the same category cannot? We either need to: 1 - Add an update to fix or warn of this existing condition 2 - Remove this restriction -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 93

[Bug 36822] New: When creating a new patron via C4::Auth_with_ldap inserts 0000-00-00 for invalid updated_on
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36822 Bug ID: 36822 Summary: When creating a new patron via C4::Auth_with_ldap inserts 0000-00-00 for invalid updated_on Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: betka(a)illinois.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Relevant versions: OS: Ubuntu 22.04 Koha: 23.11.04-4 MySQL: 8.0.36-0ubuntu0.22.04.1 When using Auth_with_ldap, new borrowers that are created via LDAP have an updated_on date of 0000-00-00 00:00:00. Guessing this may be related to comments in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18016 May also be a side effect of explicitly declaring a default_value of \"current_timestamp" for updated_on in Koha/Schema/Result/Borrower.pm. (Guessing no one else is still using LDAP to create accounts) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 66

[Bug 35125] New: AutoCreateAuthorities creates separate authorities when thesaurus differs, even with LinkerConsiderThesaurus set to Don't
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35125 Bug ID: 35125 Summary: AutoCreateAuthorities creates separate authorities when thesaurus differs, even with LinkerConsiderThesaurus set to Don't 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, nick(a)bywatersolutions.com Setup: * Set AutoCreateAuthorities to generate, AutoLinkBiblios to Do, CatalogModuleRelink to Do (and EnableAdvancedCatalogingEditor to enable if you want to make your life easier) * Ensure that LinkerConsiderThesaurus is at the default Don't * Make sure you don't have a genre authority record for Boring stories Add the following headings to a bib record and save it 655 _ _ ‡aBoring stories 655 _ 0 ‡aBoring stories 655 _ 4 ‡aBoring stories 655 _ 7 ‡aBoring stories‡2gsafd 655 _ 7 ‡aBoring stories‡2lcgft Note that you now have each heading linked to a different authid, and you have five genre authority records for Boring stories, all identical. If instead you already had a Boring stories authority record (no matter the thesaurus) before saving the record, they would have all been linked to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 37288] New: Edit data provider form does not show the name
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37288 Bug ID: 37288 Summary: Edit data provider form does not show the name Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 34587 I think bug 34587 introduced this bug. If you create a data provider then edit it, the edit form will not display the name, and the input is looking like the add form. You also see the "Create manually" button, which feels wrong. See https://snipboard.io/ELqPAB.jpg Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34587 [Bug 34587] Add a Usage Statistics module to ERM -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 37351] New: Using checkboxes on circ/aitingreserves.pl does not add them to cancellation list after changing to Page 2 or more of DataTable
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37351 Bug ID: 37351 Summary: Using checkboxes on circ/aitingreserves.pl does not add them to cancellation list after changing to Page 2 or more of DataTable Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cj.lynce(a)westlakelibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Steps to reproduce *Note for these steps to work, you must have enough holds waiting to necessitate a 2nd page of holds in circ/waitingreserves.pl 1. Log in to staff client 2. Place items on items for borrowers 2-1 Place enough holds as noted above 2-2 Trap holds for borrowers 3. Open Circulation->Holds Awaiting Pickup (circ/waitingreserves.pl) 4. Click a checkbox for one or mroe holds Note->The 'Cancel selected (0)' button changes to 'Cancel selected (1)', etc. 5. Cancel selected Holds using the (Cancel selected (#) button) 6. Confirm Cancellation 7. Wait for background processes to complete, then verify holds are cancelled. 8. Return to Open Circulation->Holds Awaiting Pickup (circ/waitingreserves.pl) 9. Ensure button shows "Cancel selected (0)" 10. Click "Next >" to navigate to page 2 of holds 11. Click a checkbox for one or more holds Note->The 'Cancel selected (0)' button DOES NOT increase as boxes are selected. 12. Cancel selected Holds using the (Cancel selected (#) button) 13. Confirm Cancellation 14. Wait for background processes to complete, then verify holds are cancelled. Note-> Holds were not cancelled The same behavior is reflected in the Holds waiting past their expiration date (Holds with cancellation requests not tested) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 38148] New: Unable to place OPAC holds and holds to pull list is empty
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38148 Bug ID: 38148 Summary: Unable to place OPAC holds and holds to pull list is empty Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is due to Bug 29087, see comment 39 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 29087] New: Holds to pull list can crash with a SQL::Abstract puke
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29087 Bug ID: 29087 Summary: Holds to pull list can crash with a SQL::Abstract puke Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Opening the holds to pull list page can crash with the following logged error: SQL::Abstract::puke(): [SQL::Abstract::__ANON__] Fatal: SQL::Abstract before v1.75 used to generate incorrect SQL when the -NOT IN operator was given an undef-containing list: !!!AUDIT YOUR CODE AND DATA!!! (the upcoming Data::Query-based version of SQL::Abstract will emit the logically correct SQL instead of raising this exception) at /usr/share/koha/lib/Koha/Objects.pm line 145 I've traced this to Koha::Holds->get_items_that_can_fill(). Among other things, this routine fetches a list of item types that cannot fill holds, i.e., cases where the 'holdallowed' rule value is 'not_allowed'. However, if your default rule is to not allow holds, the @hold_not_allowed_itypes list will end up including an entry whose value is undef. When passed to the item query, doing the -not_in filter on itype will result in the crash listed above. A quick fix might be to filter out undef from that list. That will fix the crash, but could lead to incorrect results if the default policy is to deny holds for all item types except for ones that are going to be specifically permitted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56