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

[Bug 28862] New: Add suffix to name field
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28862 Bug ID: 28862 Summary: Add suffix to name field 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: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Requesting the addition to the name field for suffix entries (Jr., Sr. III, etc.). Ideally it would be a drop-down box that could be prepopulated (auth_value?) with common entries; allowing for cleaner data and easier account viewing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 29768] New: hidepatronname hides guarantor name on borrower edit screen
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29768 Bug ID: 29768 Summary: hidepatronname hides guarantor name on borrower edit screen Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref hidepatronname is now hiding the guarantor name on memberentry.pl. This seems like a strange place to enforce that system preference since it's convenient for staff to be able to double check that info when editing patron information and personal information is already showing on that screen. It's not enforced on other patron details screens (such as moremember.pl) and I don't think it should impact patron edit screen either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 43219] New: ADJ_REASON is not installed as authorised value category
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43219 Bug ID: 43219 Summary: ADJ_REASON is not installed as authorised value category Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- ADJ_REASON is missing from auth_cal_cat.sql in the installer files and is therefore missing from new installations. It's used to add reasons to the invoice adjustments in the acq module. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42324] New: Authority auto-created from bib heading truncates trailing dots in $f date for living authors
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42324 Bug ID: 42324 Summary: Authority auto-created from bib heading truncates trailing dots in $f date for living authors Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a bibliographic record is saved with a personal name heading (example) containing a living author date in $f (e.g. “1970-….”), Koha automatically creates an authority record with a truncated $f value (“1970-…” instead of “1970-….”). One dot is silently dropped. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43218] New: Update some serials pages to use grid layout for forms - Part 1
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43218 Bug ID: 43218 Summary: Update some serials pages to use grid layout for forms - Part 1 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39780 Target Milestone: --- - serials/acqui-search.tt - serials/checkexpiration.tt - serials/routing-preview.tt - serials/routing.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41469] New: Convert Traditional Chinese to Simplified Chinese for searching
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41469 Bug ID: 41469 Summary: Convert Traditional Chinese to Simplified Chinese for searching Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have had a request for supporting the conversion of traditional characters to simplified characters There are elastic tools/analyzers for this: https://github.com/infinilabs/analysis-stconvert https://www.elastic.co/docs/reference/elasticsearch/plugins/analysis-smartcn However, in testing I have not been able to get things working. The requester suggested some config for Zebra as well, but I couldn't get that working either Filing this here to capture conversations I had with David Cook and so he can share the setup he tried ;-) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 43216] New: Clarify batch record modification: 952/995 rules only create new items
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43216 Bug ID: 43216 Summary: Clarify batch record modification: 952/995 rules only create new items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When using Batch record modification together with a MARC modification template that adds a 952 (MARC21) or 995 (UNIMARC) field/subfield, staff routinely expect this to modify existing items on the target biblios (e.g. add a collection code to items that already exist). That is not what happens. Batch record modification and its preview (svc/records/preview) both operate on the biblio's stored MARC record without embedding existing items (Koha::Biblio::Metadata->record is called without embed_items). Existing items are therefore completely invisible to the template - the template only ever sees a record with no 952/995 fields, so any 'add field' action for 952/995 produces a brand new, standalone field. At execution time (Koha::BackgroundJob::BatchUpdateBiblio), if the resulting record contains a 952/995 field the job treats it as a request to create a new item (bug 26869) and requires the mandatory subfields (homebranch, holdingbranch, itemtype) to be present, or the record fails with an error such as 'No homebranch subfield found'. The preview step applies the same template but skips this validation entirely, so staff see what looks like a harmless 952$8 being added and are then surprised when the real batch job reports per-record failures. There is currently no UI hint, warning, or documentation calling out that: - 952/995 actions in a batch record modification template only ever create new items, never edit existing ones - mandatory item fields must be supplied by the template itself or the job will fail for every affected record - the preview does not reflect this validation, so a clean preview is not a reliable indicator of success This bug is to track adding a clear warning (in the UI when 952/995 actions are configured in a template used for batch record modification, and/or in the preview screen) plus documentation, so staff are not caught out by this distinction. Batch item modification (tools/batchMod.pl) remains the correct tool for editing fields on already-existing items. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 40817] New: Holds charges should be accessible from Holds
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40817 Bug ID: 40817 Summary: Holds charges should be accessible from Holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 3492 It should be easy to get from a hold to it's associated charges.. i.e. Hold fee, Cancellation fee, any processing fees. This would be useful for API responses and display purposes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 [Bug 3492] Move hold fee setting into circulation rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52

[Bug 43214] New: Could the ILL_PICKUP_READY -notice be sent as a print (by mail)?
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43214 Bug ID: 43214 Summary: Could the ILL_PICKUP_READY -notice be sent as a print (by mail)? Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- The ILL_PICKUP_READY message can be sent by email and/or SMS. Could it also be sent by mail? If the interlibrary loan pickup notification method (email, text message) is not selected and the pickup notification is sent in the interlibrary loan module, no notification goes to the patron at all. It would be great if the ILL-pickup notification was sent to the patron by mail in that case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43140] New: Add possibility to edit the ILL pickup message before sending
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43140 Bug ID: 43140 Summary: Add possibility to edit the ILL pickup message before sending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Koha ILL module lets user to edit the (email) message you send to another library to order an ILL from them. There is a ready default message (ILL_PARTNER_REQ) for that, but you can edit the message on the go, before sending it. It would be great to be able to edit the pickup message for patron, too. When you send notice for patron, that their ILL is ready for pick-up, Koha just sends it, without any preview, even. It's great that you have a default (ILL_PICKUP_READY) for that, in different languages at best, but sometimes you need to add some information to it, so editing would make this more useful. Please note the bug about the language of the ILL_PARTNER_REQ message is chosen on wrong basis: (We don't want to copy same mistake for this.) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42501 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1