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

[Bug 38512] New: Item table status column display is wrong when record has recalls
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38512 Bug ID: 38512 Summary: Item table status column display is wrong when record has recalls Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Turn on UseRecalls 2. Set circ rules to allow for recalls ( Recalls allowed(total) and Recalls allowed(count)) 3. Check something out to a patron, choose a record with multiple items on it 4. With another patron recall the item from the OPAC 5. Choose "Recall next available item" 6. Now go back to the item table and see that all items on the bib say something like: "recalled by koha (42) on 11/21/2024" That seems incorrect, the items should still show as 'Available'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 33681] New: Omnibus: Allow SIP2 users to be created through the Koha staff interface
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33681 Bug ID: 33681 Summary: Omnibus: Allow SIP2 users to be created through the Koha staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Let's fix this - libraries ought to be able to create their own SIP users (even the part we currently manage with XML) through the Koha UI. Initial requirements: Create a user that without any touching of server side configuration files can allow a SIP login for the most basic usage of SIP. Allow those users to be configurable with all of the configuration options available through SIPConfig.xml as documented in SIPConfig.xml https://github.com/Koha-Community/Koha/blob/master/etc/SIPconfig.xml -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 18676] New: Optionally delete fast add items and records on return
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18676 Bug ID: 18676 Summary: Optionally delete fast add items and records on return 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: 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 libraries fast adds are used for ILL or other material that's not supposed to stay in the catalog after circulation was completed. It would be nice if there as an option to automatically delete fast add items and records (if it was the last item) when the item is checked-in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 20258] New: Offer circcontrol options at library level rather than at system-wide level.
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20258 Bug ID: 20258 Summary: Offer circcontrol options at library level rather than at system-wide level. Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The following is a slight simplification of our complex structure, but it outlines how Koha is not offering us a 100% satisfactory circulation experience. We have 6 college libraries all marked as closed in weekends, with users permitted to borrow (let’s say for simplification) a maximum of 15 items from across the 6 libraries. (All loan rules are the same at all 6 college libraries). All users belong to one of these libraries. Our new kit-loaning library has opened 24/7 and it offers a loan of one laptop and loans of up to three accessories (headphones etc.) with a loan period of 4 hours. No users belong to this library. Policy is to allow loans from this library to be in addition to loans from the normal 6 libraries. Having circcontrol set to either the rules from where the item is from, or the library the user is logged in at both fail to work as (even ignoring the new library) the maximum loans increases from 15 overall to 15 per library (6*15=90)- totally unacceptable here. The only option for now has been to set circcontrol to use the rules applicable to the library the user is from. This fails in two ways. Loans from the 24/7 library made at weekends are being pushed out as due on Monday (as all the libraries consulted for rules are marked as closed). Additionally the only way to allow the loans from the 24/7 library to be additional to the 15 maximum, has been to increase the maximum loans to 15+4=19. Users can of course now take 19 items out from the six main libraries, as the loan entitlement is not being compartmentalized. Option 1. We continue to put up with what we have. Option 2. We set up a second instance of Koha for only the 24/7 library, or source another product to manage loans from that library. Option 3. Move circcontrol to the library level, leave the 6 libraries with circcontrol at each library using the rules for where the user is from, and lower the maximum loans to 15 at each library. Change circcontrol for the 24/7 library to use circcontrol set to use the rules for the library the user is logged in at (or possibly where the item is from). With the calendar for the 24/7 being consulted now the weekend loan period would be right, and the loans maxima should also be right (15 from the six college libraries plus 4 for the 24/7 library using the different circcontrol. Can anyone offer any other alternatives? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31199] New: selenium/patrons_search.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31199 Bug ID: 31199 Summary: selenium/patrons_search.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 25551 19:38:24 koha_1 | # Looks like you planned 24 tests but ran 16. 19:38:24 koha_1 | 19:38:24 koha_1 | # Failed test 'Search patrons' 19:38:24 koha_1 | # at t/db_dependent/selenium/patrons_search.t line 287. 19:38:24 koha_1 | Cannot wait more for jQuery to be active (wait_for_ajax) at /kohadevbox/koha/t/lib/Selenium.pm line 206. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25551 [Bug 25551] [OMNIBUS] Some tests are failing randomly -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 20424] New: Zebra - Updating default Unimarc biblio mapping
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20424 Bug ID: 20424 Summary: Zebra - Updating default Unimarc biblio mapping Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fpichenot(a)ville-roubaix.fr QA Contact: testopia(a)bugs.koha-community.org Zebra doesn't yet integrate last Unimarc bibliographic updates published by IFLA. This ticket aims to update Zebra Unimarc bibliographic mappings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[Bug 22514] New: Hardcoded value of 10 for return hour when calculating hourly loans affected by holidays
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22514 Bug ID: 22514 Summary: Hardcoded value of 10 for return hour when calculating hourly loans affected by holidays Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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 Target Milestone: --- >From Koha/Calendar.pm: if ( $unit eq 'hours' ) { # Fixed for legacy support. Should be set as a branch parameter my $return_by_hour = 10; $dt = $self->addHours($startdate, $add_duration, $return_by_hour); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 37269] New: Saving edits to a patron - error message clears or resets some fields
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37269 Bug ID: 37269 Summary: Saving edits to a patron - error message clears or resets some 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When there is an error saving edits to a patron, some of the changes you make are cleared or reset to the previous value. Changes noted for the patron field (by section): - Patron identity: Surname reset - all other fields retain the changed values - Patron guarantor: retains values - Non-patron guarantor: Guarantor surname, Guarantor first name reset - all other fields retain the changed values (Relationship) - Main address: all fields reset - Contact information: all fields reset - Alternative address: all fields reset - Alternate contact: all fields reset - Library management: none - all keep the changed values - Library setup: none - all keep the changed values - OPAC/Staff interface login: none - all keep the changed values (not sure about the password) - Patron account flags: none - all keep the changed values - Patron restrictions: none - all keep the changed values - Additional attributes and identifiers: none - all keep the changed values - Patron messaging preferences: all fields reset (but that may be more to do with changing the patron category) To replicate: 1. Go to a patron record and edit it (I used Mary Burton). 2. Duplicate the tab so you can compare the differences. 3. Make changes to every field available. Changes I made: . Text fields: Put an 'A' in front of every existing text value or for any empty text field . For email address: me(a)example.com . For dropdown lists, selectors, or tick boxes, change to another value . For dates, change the year 4. Change a field so that it will generate an error in the info box area when you go to save. I could generate an error message by: . Changing the date of birth so that the age doesn't match the age range for the patron category - for Mary, change date of birth year to 2010 . Change the patron category so that their age is incorrect for the patron category - for Mary, change from patron to Board (I'm sure there are other ways to generate an error message.) 5. When you save the form, you get an error message (I changed the patron category for Mary from Patron to Board): The following fields are wrong. Please fix them. . Patron's age is incorrect for their category. Ages allowed are 5-17. 6. Note that: . Some fields remain the same . Many fields are reset to the value they had before making the changes (empty or original values) The issue was identified when testing Bug 31354 - Clarify options for 'Change messaging preferences to default for this category?' popup. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 37870] New: t/db_dependent/Koha/UI/Form/Builder/Biblio.t and Item.t
by bugzilla-daemon＠bugs.koha-community.org 27 May '25

27 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37870 Bug ID: 37870 Summary: t/db_dependent/Koha/UI/Form/Builder/Biblio.t and Item.t Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: RM_priority Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Jenkins is failing on: t/db_dependent/Koha/UI/Form/Builder D10 #1626 D12 #3027 -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 28794] New: ability to make a list visible for a specific period
by bugzilla-daemon＠bugs.koha-community.org 26 May '25

26 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28794 Bug ID: 28794 Summary: ability to make a list visible for a specific period Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if the visibility of a list could be programmed in advanced, for example if the list is created to support a specific event like an exhibition, or a school program. For example a list created the 1 jan 2021 could be programmed to be visible from the 1 fev 2021 to the 1 june 2021 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3