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

[Bug 40459] New: Preferred name is lost when editing partial record
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40459 Bug ID: 40459 Summary: Preferred name is lost when editing partial record 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(a)bywatersolutions.com To recreate: - have a patron with a preferred_name - click the big Edit button at the top of the record to edit the whole patron record, change something other than preferred name, click save - confirm preferred name is retained - click the edit button in the Contact Information section of the record to edit part of patron record, change something other than preferred name, click save - confirm preferred name is retained - click the edit button in **any other** section of the record to edit part of patron record, change something other than preferred name, click save - confirm preferred name is lost -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 40156] New: Advanced editor should not create empty fields and subfields
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40156 Bug ID: 40156 Summary: Advanced editor should not create empty fields and subfields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, advanced bibliographic records editor creates empty subfields (or even empty fields) when no content is placed after ‡<code> (or, in case of control fields, after <tag>). To reproduce: 1. Enable EnableAdvancedCatalogingEditor. 2. Open a record in the advanced editor, create empty subfield and empty fields, i.e.: 007 500 _ _ ‡a 246 3 1 ‡aAdditional title :‡b 3. Save the record. Go to bibliographic record Normal view and in modal "MARC preview" notice that the fields / subfields you entered as empty exist in the record with no data. This is wrong. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 40689] New: "Lost status" and "Damaged status" don't appear on moredetail.pl if user can't update them
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40689 Bug ID: 40689 Summary: "Lost status" and "Damaged status" don't appear on moredetail.pl if user can't update them Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com There's just a little bug in the display of moredetail.pl To reproduce: Set the "Damaged status", "Withdrawn status", and "Lost status" for an item on bib 29 on KTD with a privileged user. Now create a user with just the "catalogue" permission and go to http://localhost:8081/cgi-bin/koha/catalogue/moredetail.pl?biblionumber=29 NOTE: You will see the Withdrawn status, but the "Lost status" and "Damaged status" won't appear. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 40488] New: "Public lists" breadcrumb link doesn't work when editing public list in staff interface
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40488 Bug ID: 40488 Summary: "Public lists" breadcrumb link doesn't work when editing public list in staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you go to http://localhost:8081/cgi-bin/koha/virtualshelves/shelves.pl?op=edit_form&s… and try to click "Public lists" in the breadcrumbs, it just takes you to http://localhost:8081/cgi-bin/koha/virtualshelves/shelves.pl?op=edit_form&s… Note the hash on the end of the URL after clicking the breadcrumb. Note that this only affects public lists. Private/Your lists works. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 40807] New: Quick add form does not include 'username' when it is included in BorrowerMandatoryFields
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40807 Bug ID: 40807 Summary: Quick add form does not include 'username' when it is included in BorrowerMandatoryFields 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: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The username field does not seem to appear on the quick add form when it is added to the list of mandatory / required fields in BorrowerMandatoryField, despite appearing as required on the full 'Add patron' form. Found on 24.11, 25.05, and main. (This occurs regardless of the number of mandatory fields selected.) To replicate: 1. Login to the Koha staff interface 2. Search system preferences for BorrowerMandatoryField 3. Toggle on Username (userid) 4. Navigate to /cgi-bin/koha/members/memberentry.pl?op=add_form&categorycode=PT, notice that username shows and is marked as required 5. Navigate to /cgi-bin/koha/members/memberentry.pl?op=add_form&categorycode=PT&quickadd=true, notice no username field shows. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 40937] New: No option to show/hide data menu in report results when including borrowernumber
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40937 Bug ID: 40937 Summary: No option to show/hide data menu in report results when including borrowernumber Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 37188 When borrowernumber was added as an option for batch patron action from reports, it didn't get added to the IF statement that makes the Show/Hide Data Menus button appear. It only knows to show up for cardnumber, biblionumber, itemnumber, or reserve_id. (https://github.com/Koha-Community/Koha/blob/99283025fc4ca0fa1c096344a47b380…) In a fun little twist, we told Koha to not set batch_cardnumbers if batch_borrowernumbers was already set, to stop the batch operations from showing up twice. (https://github.com/Koha-Community/Koha/blob/99283025fc4ca0fa1c096344a47b380…) To recreate: 1 - save and run "SELECT borrowernumber FROM borrowers" - no Show/Hide button 2 - save and run "SELECT cardnumber FROM borrowers" - yes Show/Hide button! 3 - save and run "SELECT cardnumber, borrowernumber FROM borrowers" - no Show/Hide button 4 - save and run "SELECT cardnumber, borrowernumber, itemnumber FROM issues LEFT JOIN borrowers USING (borrowernumber)" - yes Show/Hide button! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37188 [Bug 37188] Batch patron modification from report results should be an option when borrowernumber is selected -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39881] New: Add patron cardnumber to On hold for column on transferstoreceive page
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39881 Bug ID: 39881 Summary: Add patron cardnumber to On hold for column on transferstoreceive page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 It would be nice if the patron's cardnumber was included in the 'On hold for' column on transferstoreceive.tt -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 39423] New: Column checkboxes on item batch modification hide incorrect columns
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39423 Bug ID: 39423 Summary: Column checkboxes on item batch modification hide incorrect columns Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It looks like the 'Hold' column is not taken into account in the numbering, unchecking any column removes the next column over -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 39623] New: "make install" re-runs "make" process unnecessarily
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39623 Bug ID: 39623 Summary: "make install" re-runs "make" process unnecessarily Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Have you ever noticed that "make install" seems to do all the same things as "make" plus install? This became even more obvious after bug 32609. And it got me thinking... surely there has to be a better way and it looks like there is. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 39570] New: Add item form includes itemnumber while adding a new item
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39570 Bug ID: 39570 Summary: Add item form includes itemnumber while adding a new item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor 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 Depends on: 36192 Luckily, submitting an itemnumber that's either empty or bogus while adding a new item doesn't actually do anything since the code for op == 'cud-additem' doesn't ever look at itemnumber, but it's confusing and scary looking in the case where you add an item after editing an existing item. The template looks at [% IF op != 'add_item' %] to decide to add the <input type="hidden" name="itemnumber" value="[% itemnumber | html %]" />. Prior to the bug 36192 CSRF protection, that worked, but now the op for adding an item is cud-additem, so it's always true and we always submit an itemnumber. And without bug 27625 it would have been less scary looking, since before then while processing the editing of an item we cleared $itemnumber after we were done using it, so it at least would have been value="". Now, if you edit an existing item and then add another, the form you submit to add an item includes the itemnumber of the item you previously edited. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14