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

[Bug 41138] New: Batch record modification via MARC modification template overwrites equal fields.
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41138 Bug ID: 41138 Summary: Batch record modification via MARC modification template overwrites equal fields. Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: int(a)free.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I want to batch correct a URL in the MARC-Data. So I created a MARC modification templates as described in the manual (see the proxy URL example): https://koha-community.org/manual/25.05/en/html/cataloging.html#marc-modifi… I did "Copy and replace" over "All" field(s) "856 u" to field "856 u" with Regex "s/deposit.d-nb.de/deposit.dnb.de/g" if field "856 u" matches "m/deposit.d-nb.de/" RegEx The fields in the original record look like this: 856 42 _u http://d-nb.info/1050788141/04 _3Inhaltsverzeichnis 856 42 _u http://deposit.d-nb.de/cgi-bin/dokserv?id=4659369&prov=M&dok_var=1&dok_ext=… _3Inhaltstext 856 42 _u http://www.perlentaucher.de/buch/barbara-sichtermann/ich-rauche-zigarren-un… _3Rezension After applying the template, I would expect that only the middle one gets modified. Instead I get this: 856 42 _uhttp://deposit.dnb.de/cgi-bin/dokserv?id=4659369&prov=M&dok_var=1&dok_ext=htm _3Inhaltsverzeichnis 856 42 _uhttp://deposit.dnb.de/cgi-bin/dokserv?id=4659369&prov=M&dok_var=1&dok_ext=htm _3Inhaltstext 856 42 _uhttp://deposit.dnb.de/cgi-bin/dokserv?id=4659369&prov=M&dok_var=1&dok_ext=htm _3Rezension It doesn't matter if I do "All" field(s) or "1." field(s) in the template, the result is the same. This is probably related to and maybe not the same as Bug 28231 - MARC modification template "1st" vs "Every" bug? and Bug 34508 - MARC modification templates have poor results when working with multiple of a field I think this bug is severe as it can go unnoticed and lead to data loss in a lot of records. Unnoticed because if you only have one field everything looks good and only multiple equal fields get overwritten. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39205] New: Have a way to add optional fields to patron search that won't be included in a standard search
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39205 Bug ID: 39205 Summary: Have a way to add optional fields to patron search that won't be included in a standard search Change sponsored?: --- Product: Koha Version: unspecified 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 It would be nice if there was a way to add some search fields that could be optionally chosen by staff when running a patron search but not included in the standard search. Example, I want to sometimes search a borrowernote but I don't want to add it to DefaultPatronSearchFields so that all standard searches are searching borrowernote. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 39162] New: SCO error messages when checking in are misleading
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39162 Bug ID: 39162 Summary: SCO error messages when checking in are misleading Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: katariina.pohto(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org When checkin in an item that hasn't been checked out SCO gives the error message: "Item not checked in: please see circulation staff for assistance" which is misleading. One might think the item has been checked out and remains so. Also, there is usually no need to contact staff when returning an item that hasn't been actually checked out. This error messages seems to be a default check-in error message. It says the same when trying to return a non-existent barcode. Which is also misleading and should really say that the item doesn't exist. Would it be possible to differentiate the possible check-in errors and give better feedback to user? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 33473] New: Allow to send email receipts for payments/writeoff manually instead of automatically
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33473 Bug ID: 33473 Summary: Allow to send email receipts for payments/writeoff manually instead of automatically Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 31448 With bug 31448 it's possible to re-send a failed or lost email receipt. It would be nice if you could turn off the automatic sending of receipts by email and send them just manually whenever requested. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31448 [Bug 31448] Add option to re-send email receipt when UseEmailReceipts is enabled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 29140] New: Suppress some warnings in codemirror js editor
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29140 Bug ID: 29140 Summary: Suppress some warnings in codemirror js editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 When editing user JS preferences there are warns for: 'let' is available in ES6 I think we could suppress these and allow that usage -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 20508] New: Validation for *MandatoryField and *UnwantedField sysprefs
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20508 Bug ID: 20508 Summary: Validation for *MandatoryField and *UnwantedField sysprefs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When any the system preferences BorrowerMandatoryField BorrowerUnwantedField PatronSelfModificationBorrowerUnwantedField PatronSelfRegistrationBorrowerMandatoryField PatronSelfRegistrationBorrowerUnwantedField are being populated, we should check that a) The entered fields are columns in the borrowers table b) Mandatory / Unwanted fields that refer to the same form (BorrowerMandatoryField/BorrowerUnwantedField and PatronSelfRegistrationBorrowerMandatoryField/PatronSelfRegistrationBorrowerUnwantedField) do not contain the same fields. c) If autoMemberNum is set, don't allow cardnumber in *MandatoryField See also: * Bug 17433 * Bug 19642 * Bug 19225 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22848] New: Ability to merge suggestions
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22848 Bug ID: 22848 Summary: Ability to merge suggestions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- It can easily happen that multiple suggestions for the same record are made. It would be nice if there was an option to merge them and keep both patrons who made the suggestion linked to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 34295] New: Staff-only extended attributes break self-registration
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34295 Bug ID: 34295 Summary: Staff-only extended attributes break self-registration Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: JBoyer(a)equinoxOLI.org QA Contact: testopia(a)bugs.koha-community.org If any patron extended attributes are defined that are mandatory and not opac-editable (such as Address Verified: Yes / No) patron self-registration will always return a 500 error because the mandatory attribute is not / can not be supplied. Avoiding this by limiting mandatory attributes to a specific patron category fails as soon as you want to apply an attribute to 2 or more categories. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 25911] New: Chrome tries to save patron passwords
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25911 Bug ID: 25911 Summary: Chrome tries to save patron passwords Change sponsored?: --- Product: Koha Version: 19.11 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.m.hall(a)gmail.com If you are like me, you might have your browser try to save passwords for sites. I like having the browser in my office save some of my passwords. Logging into Koha is one of them. However, the problem with this is, every time I save a form that has a password associated with it, it wants to remember this password. This includes patron records. This is an annoyance. Now, my testing has been only with Chrome on this particular issue, and my workaround addresses this to some degree. So, if there is a more all-encompassing issue to address or solution, feel free to chime in. I've been able to work around this annoyance by adding the following to jQuery: $('#pat_memberentrygen #password,#pat_memberentrygen #password2').attr('readonly','').attr('onfocus','$(this).removeAttr("readonly");'); This will make the password fields readonly, which Chrome will ignore. If you need to edit the field, when you click on it, it will take the readonly attribute away, and it can be edited. Left as is, when you save, it will, of course, try to save the password. But it will only do so if the password is edited. If you leave it untouched, it will not bug you. I can take this one step further, I add this line to add the readonly attributes before saving. Then it won't bug me to save the password at all: $('#pat_memberentrygen #validate').attr('onmouseover', '$("#pat_memberentrygen #password,#pat_memberentrygen #password2").attr("readonly","");'); NOTE: Our Save button has the ID of "validate" because I have some validation code added to the form. But you get the idea here. When you hover over the save button, it adds the readonly attribute, and is ignored by the browser. I don't know if this helps anyone, or gives anyone an idea how to keep patron forms from being a nuisance to staff that save credentials, but I thought I would throw it out here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 36256] New: Port default MEMBERSHIP_EXPIRY notice to Template Toolkit syntax
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36256 Bug ID: 36256 Summary: Port default MEMBERSHIP_EXPIRY notice to Template Toolkit syntax Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: roadmap_24_05 Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 15278 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14