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

[Bug 39415] New: Add subfield g to Geogrpahic name authority fields
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39415 Bug ID: 39415 Summary: Add subfield g to Geogrpahic name authority fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Subfield g is a valid subfield - we should respect it if present: https://www.loc.gov/marc/authority/adx51.html https://www.loc.gov/marc/authority/ad151.html -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 38650] New: We should only fill title level or specific item holds when a patron checks out an item
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38650 Bug ID: 38650 Summary: We should only fill title level or specific item holds when a patron checks out an item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 Follow up to bug 14549 - we handled the case here to fill a patron's reserve when they get another copy, however, we didn't cover the case where their reserve is title level. To recreate: 1 - Place a hold for patron A on item #1 of a record 2 - Place a hold for patron B on item #2 of a record 3 - Issue item #2 to patron A - their hold on item #1 is filled incorrectly -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 17338] New: waitingreserves.pl should keep you on the same tab when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Bug ID: 17338 Summary: waitingreserves.pl should keep you on the same tab when cancelling a hold 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you cancel a hold on the Hold(s) over tab, and the process is done, it puts you back on the Hold(s) waiting tab. It should keep you on the same tab. It would also be nice if the search box is used that it would keep the focus. We use the following jQuery to help streamline the cancelling process: //Default Holds awaiting pickup to Holds over tab $("#holdso form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); if (window.location.href.indexOf("cgi-bin/koha/circ/waitingreserves.pl#holdsover") > -1) { $("form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); } setTimeout(function() { $("#holdso_filter input").focus(); },10); //End default tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 39710] New: Cannot load holds history if there are deleted biblios
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39710 Bug ID: 39710 Summary: Cannot load holds history if there are deleted biblios Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 To recreate: - place a hold - cancel the hold - look in patron hold history, see the title - delete the biblio - reload patron hold history, error [2025/04/23 11:43:28] [WARN] OpenAPI >>> GET api/v1/patrons/5/holds [{"message":"Expected integer - got null.","path":"\/body\/3\/biblio_id"},{"message":"Expected integer - got null.","path":"\/body\/4\/biblio_id"}] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 39915] New: Late issues export exports empty rows
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39915 Bug ID: 39915 Summary: Late issues export exports empty rows Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org To reproduce 1) Create a new subscription, setting the vendor id as 1 2) Set the subscription start date as yesterday's date, the other details aren't relevant so set whatever you want 3) Click into claims 4) If you get a warning saying no claims notice is defined then click the link to define one (on the dropdown for the 'New notice' button you want 'Claim serial issue. The content of the notice isn't relevant here so input anything). Then head back to the claims page. If no warning shows, proceed to the next step 5) Choose My Vendor and hit OK 6) You should see a table of claims with the first issue for your new serial 7) Click the checkbox next to the row 8) Click the 'Download selected claims' button at the bottom 9) The CSV will download 10) Click into it - it will have the header but the rows will be blank -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 39644] New: Too many borrower_relationships causes patron page to not load
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39644 Bug ID: 39644 Summary: Too many borrower_relationships causes patron page to not load Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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: In k-t-d, if I add 53 guarantees for Edna Acosta it takes about 8-10 seconds for the patron page to load. If I add 700 guarantees for Edna Acosta the page won't load and I ultimately get a time out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 39414] New: Item type not retained when editing a booking
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39414 Bug ID: 39414 Summary: Item type not retained when editing a booking Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When editing an existing booking, the Patron, Pickup at, and Item are retained, but the Itemtype will be de-selected. The booking cannot be edited until the item type is re-selected. The booking dates are also not retained in the edit booking window, but this was existing behavior. To re-create: 1. Place a booking on an item. 2. Click on edit to open the Edit booking modal. 3. The item type will be de-selected, and the booking dates calendar will be locked until the item type is re-selected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 39397] New: Searching a biblio by timestamp returns a different timestamp
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39397 Bug ID: 39397 Summary: Searching a biblio by timestamp returns a different timestamp Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com When crafting a search including the `timestamp` field, the comparison is made against the `biblio.timestamp` column. But the result displays the `biblioitem.timestamp`. I believe filtering and the returned objects should be consistent. On the other hand, I feel like the real source for truth is the biblio_metadata.timestamp column. Thoughts? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 39056] New: Do not copy preferred_name to new patron when using Duplicate
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39056 Bug ID: 39056 Summary: Do not copy preferred_name to new patron when using Duplicate Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the Duplicate button from a patron's record, we make a new patron with some of the original patron's info. We bring the surname to the new patron, but not the firstname. Following that logic, we shouldn't copy preferred_name, either. Currently on main the preferred_name *is* copied to the new patron. In the long run this probably wants something like the PrefillGuaranteeField syspref, but in the short term we should just exclude preferred_name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 38927] New: Unecessary call to FindDuplicate if x-confirm-not-duplicate is passed to POST /biblios
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38927 Bug ID: 38927 Summary: Unecessary call to FindDuplicate if x-confirm-not-duplicate is passed to POST /biblios Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 31800 695 my ( $duplicatebiblionumber, $duplicatetitle ); 696 ( $duplicatebiblionumber, $duplicatetitle ) = FindDuplicate($record); 697 698 my $confirm_not_duplicate = $headers->header('x-confirm-not-duplicate'); 699 700 return $c->render( 701 status => 400, 702 openapi => { 703 error => "Duplicate biblio $duplicatebiblionumber", 704 } 705 ) unless !$duplicatebiblionumber || $confirm_not_duplicate; We don't need to call FindDuplicate if the header is set. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31800 [Bug 31800] Add POST endpoint for Biblios -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14