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

[Bug 40016] New: Search within results is broken for publication date
by bugzilla-daemon＠bugs.koha-community.org 28 May '25

28 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40016 Bug ID: 40016 Summary: Search within results is broken for publication date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Steps to reproduce (ktd, zebra), pb can be reproduced with es. 1 - Make sure the syspref IntranetCatalogSearchPulldown is active. 2 - Type jean in advanced search -> you get three results (url: http://koha-ktd:8081/cgi-bin/koha/catalogue/search.pl?advsearch=1&op=AND&id…) 3 - In Search within results, select publication date in the dropdown, and type 1990-2000 -> broken (url: http://koha-ktd:8081/cgi-bin/koha/catalogue/search.pl?idx=kw&q=jean&&&limit…) 4 - Type jean in advanced search, click on more options, fill "1990-2000" in 'limit' -> it works ! (url: http://koha-ktd:8081/cgi-bin/koha/catalogue/search.pl?advsearch=1&op=AND&id…) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35305] New: Add XSLT for authority detail page in staff interface
by bugzilla-daemon＠bugs.koha-community.org 28 May '25

28 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35305 Bug ID: 35305 Summary: Add XSLT for authority detail page in staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Like Bug 11083 for result display, allow XSLT for details display in staff interface -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 23486] New: Date last seen should be set upon registration
by bugzilla-daemon＠bugs.koha-community.org 28 May '25

28 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23486 Bug ID: 23486 Summary: Date last seen should be set upon registration 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a patron is registered, via staff or self registration we should fill in the 'lastseen' field -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 70

[Bug 40014] New: Preservation module does not support authorized value ETAT
by bugzilla-daemon＠bugs.koha-community.org 28 May '25

28 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40014 Bug ID: 40014 Summary: Preservation module does not support authorized value ETAT Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Preservation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com Many UNIMARC installation uses the authorized value "ETAT" (present in default Koha but not used by default) instead of "NOT_LOAN". This is not taken into account in the preservation module. This can lead to invalid value when field 995$o (status or not for loan) is filled by Koha with a value in the authorized value "NOT_LOAN" that is not present in the authorized value "ETAT" that is mapped to the 995$o. To reproduce : O- On a UNIMARC Koha 1- Add some values in the authorized value ETAT 2- Make sure the authorized value NOT_LOAN contains at least a value that is not in ETAT. 3- Update the Default bibliographic framework field 995, subfield o to use the authorized value ETAT. 4- Activate the preservation Module with the system preference PreservationModule. 5- Select a value that is in NOT_LOAN but not in ETAT in system preferences PreservationNotForLoanDefaultTrainIn and PreservationNotForLoanWaitingListIn. 6- Go in the preservation module 7- Pick an item with an emtpy 995$o and add this item to the waiting list 8- Modify the item, check that the 995$o now contains an invalid value in field 995$o, the value in the field is followed by "(Not an authorised value") -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39986] New: OPACdidyoumean, acting like a system preference when it is not
by bugzilla-daemon＠bugs.koha-community.org 28 May '25

28 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39986 Bug ID: 39986 Summary: OPACdidyoumean, acting like a system preference when it is not Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration 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 OPACdidyoumean has an entry in sysprefs.sql: ('OPACdidyoumean','',NULL,'Did you mean? configuration for the OPAC. Do not change, as this is controlled by /cgi-bin/koha/admin/didyoumean.pl.','Free'), You can also find it in the systempreference table: select * from systempreferences where varibale = 'OPACdidyoumean'; However, it can be be found when you search for it as a system preference. If you go to `admin/didyoumean.pl` and make changes they are logged as a change to a system preference. This is confusing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[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