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

[Bug 30717] New: Date format doesn't change in additem for dateaccessioned
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30717 Bug ID: 30717 Summary: Date format doesn't change in additem for dateaccessioned Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mengu(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, After upgrade from 19.05 to 21.11.04 we got a problem with additem section. dateaccessioned area of additem doesn't seem correctly even we changed dateformat in systempreferences. I've removed the blank in the line var dateformat_pref = "[% Koha.Preference('dateformat') | html %]"; of calendar.inc -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 36376] New: Display library limitations issue in patron's messages
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36376 Bug ID: 36376 Summary: Display library limitations issue in patron's messages 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: 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 31422 added a warning message when library limitations issue in patron edition page. We should add this patron's messages in circ and details pages. Like age limitations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 36421] New: REST API 500 errors say to check the logs, but suppress errors that would be there
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36421 Bug ID: 36421 Summary: REST API 500 errors say to check the logs, but suppress errors that would be there Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com CC: tomascohen(a)gmail.com If a REST auth error happens that that is unblessed or uncaught, we should warn the value to the logs. Test Plan: 1) Install the curbside pickups plugin 2) create a patron with the userid 'puser' and the cardnumber 'pcard' 3) GET /api/v1/contrib/curbsidepickup/patrons/XXX/pickups using basic auth with the username 'pcard' where XXX is the patron borrowernumber 4) Note there is no error in the logs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 36227] New: No warning if placing hold on item group with no items
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36227 Bug ID: 36227 Summary: No warning if placing hold on item group with no items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It is currently possible to place a group-level hold on an item group with no items in it, both from the staff client and OPAC. This results in a hold that is not fillable unless the item group is deleted or an item is added into it. A warning would be helpful so patrons aren't left with an unfillable hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 34823] New: Do not show item group drop-down if there are no item groups
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34823 Bug ID: 34823 Summary: Do not show item group drop-down if there are no item groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When EnableItemGroupHolds is activated, there is a "Request specific item group:" drop-down in the OPAC when placing a hold. However, this drop-down appears regardless of whether the record has item groups or not. I think this may be confusing for patrons. To replicate: 1. Enable EnableItemGroups and EnableItemGroupHolds 2. Go to the OPAC and log in as a patron 3. Go to any record that doesn't have grouped items and try to place a hold 4. Click on "Show more options" --> Note that there is an option to choose an item group with the only option being "Any item group" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 36347] New: Return claims table is loaded twice
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36347 Bug ID: 36347 Summary: Return claims table is loaded twice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The issue is caused by these lines in circulation.js: $("#finesholdsissues a[data-toggle='tab']").on("shown.bs.tab", function(e){ $(this).click(); }); When the user clicks on a hidden tab, 'shown.bs.tab' is triggered and then another click event is triggered. And because the table is loaded on tab click, it is loaded twice. Visually it can cause the rows to be duplicated (it is random, probably due to timing, network latency, ...) -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 36392] New: Only 20 vendors in ERM dropdown
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36392 Bug ID: 36392 Summary: Only 20 vendors in ERM dropdown Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: caroline.cyr-la-rose(a)inlibro.com 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 When there are more than 20 vendors in acquisitions, only 20 appear in the New agreement dropdown list. To recreate: 1. Enable the ERMModule system preference 2. In Acquisitions, create more than 20 vendors (see below for an sql insert that I used) 3. Go to E-resource management > Agreements > New agreement 4. Open the vendor dropdown --> It stops at Sierra (or the 20th vendor if you created your own) 5. Type "Tango" or "Zulu" (or one of the names of your 21st+ vendor) --> No results This is what I used to create all the vendors INSERT INTO aqbooksellers (name,active) VALUES ('Alpha','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Bravo','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Charlie','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Delta','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Echo','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Foxtrot','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Golf','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Hotel','1'); INSERT INTO aqbooksellers (name,active) VALUES ('India','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Juliet','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Kilo','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Lima','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Mike','1'); INSERT INTO aqbooksellers (name,active) VALUES ('November','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Oscar','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Papa','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Quebec','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Romeo','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Sierra','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Tango','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Uniform','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Victor','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Whiskey','1'); INSERT INTO aqbooksellers (name,active) VALUES ('X-Ray','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Yankee','1'); INSERT INTO aqbooksellers (name,active) VALUES ('Zulu','1'); Paul D. pointed me to the RESTdefaultPageSize system preference which does affect the dropdown. If I change the syspref to 50, I can see all the vendors in the dropdown. The problem with this is that I'm not sure what else this syspref affects. I have a client with 674 vendors, I don't want to put 1000 in the syspref and then somewhere else something takes forever to load because of this. I'm not sure what is happening here. I found bug 32474 and bug 32468 that seem to deal with this and that are marked as fixed, but I don't see the correct behaviour in ktd with master. I hope someone else can confirm or invalidate this... The client who pointed this out to me (the one with 674 vendors) is on 23.05.05, which already has the patches from bug 32468. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 34663] New: Unimarc Default framework
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34663 Bug ID: 34663 Summary: Unimarc Default framework Change sponsored?: --- Product: Koha Version: master 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: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org New install Koha 23.05.02 Please correct in the Unimarc Default framework. subfields not in same tabs Not all subfields for the following tags are in the same tab (or marked 'ignored'). Code Description Tag Tabs in use Default framework 410 3,4 Default framework 411 3,4 Default framework 412 3,4 Default framework 413 3,4 Default framework 421 3,4 Default framework 422 3,4 Default framework 423 3,4 Default framework 424 3,4 Default framework 425 3,4 Default framework 430 3,4 Default framework 431 3,4 Default framework 432 3,4 Default framework 433 3,4 Default framework 434 3,4 Default framework 435 3,4 Default framework 436 3,4 Default framework 437 3,4 Default framework 440 3,4 Default framework 441 3,4 Default framework 442 3,4 Default framework 443 3,4 Default framework 444 3,4 Default framework 445 3,4 Default framework 446 3,4 Default framework 447 3,4 Default framework 448 3,4 Default framework 451 3,4 Default framework 452 3,4 Default framework 453 3,4 Default framework 454 3,4 Default framework 455 3,4 Default framework 456 3,4 Default framework 461 3,4 Default framework 462 3,4 Default framework 463 3,4 Default framework 464 3,4 Default framework 470 3,4 Default framework 481 3,4 Default framework 482 3,4 Default framework 488 3,4 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 36371] New: Patron attributes will not show in brief info if value is 0
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36371 Bug ID: 36371 Summary: Patron attributes will not show in brief info if value is 0 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: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, nick(a)bywatersolutions.com A patron attribute will not show in the patron brief information if the value for that attribute is 0. This presents an issue for attributes using the YES_NO authorised value, which stores as 1/0. To recreate: 1 - create a patron attribute: check "display in patron's brief info" and tie to the YES_NO authorised value 2 - Find a patron, set your attribute to Yes 3 - Confirm you see the attribute and its value both in the "Additional attributes and identifiers" section of the patron detail page and in the patron brief info area 4 - Set your attribute to No 5 - Confirm you see the attribute and its value in "Additional attributes and identifiers" but it no longer shows in the brief info 6 - Edit your YES_NO authorised value so the codes are Y for Yes and N for No 7 - Find a new patron, repeat steps 2-5, confirm that your No value does show in brief info when the code is N rather than 0 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 35943] New: SQL reports groups/subgroups whose name contains regexp special characters break table filtering
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35943 Bug ID: 35943 Summary: SQL reports groups/subgroups whose name contains regexp special characters break table filtering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Reports Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Groups and subgroups filtering uses regular expressions. The filter looks like "^" + name + "$" The problem is that the special characters in group/subgroup name are not properly escaped, which means that if a name contains "+", "*", or any other regexp special characters, filtering will probably fail. Another (minor) problem is that we use the name to filter instead of the code. So if we have two groups or two subgroups with the same name, it will show reports from both groups/subgroups. There is no reason to have groups/subgroups with the same name, but it is possible (whereas it's not possible to have different groups/subgroups with the same code), so this should be fixed too. -- You are receiving this mail because: You are watching all bug changes.

1 13