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

[Bug 39334] New: Preserve order when saving patron attributes
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39334 Bug ID: 39334 Summary: Preserve order when saving patron attributes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A changed introduced in Bug 26744 affects the order in which patron attribtes are saved, so that one no longer can rely on that the attribute ids are assigned in the same order as the data was passed in. This has very minor implications in Koha itself. since attributes are sorted by other columns when retrieved. but many tests in t/db_dependent/api/v1/patrons_extended_attributes.t now fail because of this. This patch makes sure the order is preserved when saving the attributes, and tests should now work again. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 41194] New: Autobarcode not incrementing when receiving serial
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41194 Bug ID: 41194 Summary: Autobarcode not incrementing when receiving serial Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To replicate: 1. Enable the system preference Autobarcode. Select incremental EAN-13 barcodes. 2. Add a subscription to a bibliographic record. Be sure to select the option to create item records when receiving. 3. Receive an item. Click in the box for barcode and see the barcode autofill. Save 4. Receive a second item. Click in the box for barcode and see the previous barcode is inserted. Save fails because of the duplicate barcode. I would expect the barcodes to increment properly. Tested on 25.05 in a sandbox. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41192] New: Publication date displays in holding table with enumeration
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41192 Bug ID: 41192 Summary: Publication date displays in holding table with enumeration Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To replicate: 1. Find a bibliographic record and add a monthly subscription. 2. Receive a few issues. 3. View the bibliographic detail of the record and holdings table. Notice the publication date is included with the enumeration generated from the numbering pattern in the holding table. The date is contained within parenthesis. 4. Edit the item record and look at the 952$h. See the field does not have the publication date. 5. Go back to the holdings table and click on the subscription tab. See the subscription table has a column for publication date. 6. View the record in the OPAC. Notice the publication date in the enumeration column of the holdings table. Also notice the Subscriptions tab with the publication date. The addition of the publication date in the holdings table enumeration column feels cluttered and repetitive. If the publication date is in the subscriptions tab, does it need to be in the holdings table as well? In addition, the insertion of the publication date in the column does not make it editable from the item form since it does not appear in the 952$h when editing (perhaps this is intentional?) I propose removing the publication date from the holdings table or, at least, making it optional. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13870] Add warnings about subscriptions and orders when deleting items
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13870 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber(a)kit.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41191] New: Multiselect in borrower attributes
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41191 Bug ID: 41191 Summary: Multiselect in borrower attributes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com I know that it is possible to make a patron attribute repeatable, but I am wondering if it would be possible or beneficial if a patron attribute, if assigned to an authorized value, could it be made so that you could multiselect from that list, like we do with the library limitations, and have those values stored in the field with the separator? This would give us the option of using repeatable fields or having one with multiple choices, and taking up less real estate on the screen if many selections are made/needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 19220] New: Allow XSLT procsessing for Z39.50 authority targets like for bibliographic targets
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19220 Bug ID: 19220 Summary: Allow XSLT procsessing for Z39.50 authority targets like for bibliographic targets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When configuring a bibliographic Z39.50 targets it's possible to list XSL scripts that change the record on import. While the option is also offered when adding authority Z39.50 targets, it doesn't work/hasn't been implemented. It would be great if this feature was available for both types of targets. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 32380] New: There should be a staff side equivalent to PatronSelfRegistrationEmailMustBeUnique
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32380 Bug ID: 32380 Summary: There should be a staff side equivalent to PatronSelfRegistrationEmailMustBeUnique 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have the ability to enforce unique email address from self reg. We should have a staff side equivalent. When using SSO it can be problematic to have the same email address on different accounts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35440] New: Partial refund triggers a 500 error
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35440 Bug ID: 35440 Summary: Partial refund triggers a 500 error Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(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. Create a charge on a patron account of $150.00 2. Pay the charge as cash 3. Issue a refund, but only refund $5.00 as cash 4. See that it causes a 500 error I should be able to issue a partial refund and have it show correctly in the transaction table. Error statement: Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Amount to payout (5.00) is higher than amountoutstanding (0)' May be connected to bug 30027 and previously fixed bug 8770. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 41189] New: List of libraries in the Location column of staff interface search results sorts by branchcode
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41189 Bug ID: 41189 Summary: List of libraries in the Location column of staff interface search results sorts by branchcode Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucy.vaux-harvey(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com As only the branchname is visible in this display it would be preferable to order alphabetically by the branchname rather than the branchcode. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply CC| |lucas(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0