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

[Bug 21627] New: System preference for recipient emails of gather_print_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21627 Bug ID: 21627 Summary: System preference for recipient emails of gather_print_notices.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I think it would be nice if the librarians without shell access to the server could change the email address list that the gather_print_notices.pl cronjob uses to send emails to. Now the only way is to specify the --email option when running the script. I suggest a system preference for this that would have a comma separated list of emails. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42557] New: Additional fields (additional-fields.pl) needs options for displaying
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42557 Bug ID: 42557 Summary: Additional fields (additional-fields.pl) needs options for displaying Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Additional fields, especially for libraries, needs options to display the field in the OPAC as well as the library list in the staff client (branches.pl). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 32767] New: Trimming of attribute types by wish (if enabled)
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32767 Bug ID: 32767 Summary: Trimming of attribute types by wish (if enabled) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, nugged(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 42554] New: Deprecate CanItemBeReserved and CanBookBeReserved in favor of Koha::Availability
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42554 Bug ID: 42554 Summary: Deprecate CanItemBeReserved and CanBookBeReserved in favor of Koha::Availability Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42386 Blocks: 40257 CanItemBeReserved and CanBookBeReserved in C4::Reserves are now thin wrappers around Koha::Item::Availability::Hold (Bug 42386). This bug covers: 1. Add overrides support to Koha::Item::Availability::Hold and Koha::Patron::Availability::Hold 2. Add Koha::Biblio::Availability::Hold for biblio-level holds 3. Wire into Koha::REST::V1::Holds::add replacing the three separate calls 4. Make Koha::Patron->can_place_holds a wrapper around the patron availability class 5. Deprecate CanItemBeReserved, CanBookBeReserved, and can_place_holds 6. Migrate remaining callers Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40257 [Bug 40257] Add Confirmation Flow to POST /holds https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42386 [Bug 42386] Unify hold availability checks into Koha::Availability pattern -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 42525] New: Records imported thru Acquisitions drops the 856 tag
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42525 Bug ID: 42525 Summary: Records imported thru Acquisitions drops the 856 tag Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I think this is related to Bug 38007, but probably still warrants a separate bug. To replicate 1. Set UseACQFrameworkForBiblioRecords 2. Prepare a MARC record for import. The MARC record should be a full record with titles, subjects, control fields, etc. Be sure to add an 856 with appropriate fields filled out to include a link. 3. Double check the ACQ framework. Notice the framework does not include all tags. In my example the ACQ framework only has these fields: 020, 022, 100, 245, 250, 260, 440, 490, 590, 942, and 952. 4. Find a basket and add an order to the basket from a new file. 5. Click through to the bibliographic record from the order line and look at the MARC. Notice many of the tags were retained but the 856 tag was not. The record was saved in the Default framework, but somehow the 856 tag was not retained. The solution to this was to modify the ACQ framework and add the 856 tag. From there the 856 tag in the record is retained when the file is imported via Acquisitions. The behavior is a bit inconsistent. For example, the ACQ framework did not have control fields or 65X tags, but they were retained when the record was saved in the Default framework. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42552] New: Reformat examples for UpdateNotForLoanStatusOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42552 Bug ID: 42552 Summary: Reformat examples for UpdateNotForLoanStatusOnCheckin Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: anna.leissle(a)bsz-bw.de UpdateNotForLoanStatusOnCheckin includes some usage examples, but they are quite hard to read in the normal font. For example it's very easy to miss the spaces needed in front of the second lines: _ALL: -1: 0 CR: 1: 0 BK -1: 0 If we changed this to <code> it would help readability. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41552] New: Holds are not removed from holds queue when hold is suspended
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41552 Bug ID: 41552 Summary: Holds are not removed from holds queue when hold is suspended Initiative type: --- Sponsorship --- status: 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If one is not using the real time holds queue, holds are not removed from the queue when suspended. Instead, they remain listed until the next time the cron is run. We should remove holds from the queue immediately when suspended, as we do when a hold is filled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 41732] New: Default order quantity should be 1 unless items are created on ordering
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41732 Bug ID: 41732 Summary: Default order quantity should be 1 unless items are created on ordering Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This issue was raised by our local librarians who create a large number of acquisition orders, most of which are for a single copy. With the current behaviour, the quantity field defaults to 0, which means that every new order requires an extra click and a manual edit of the quantity field; otherwise, saving triggers a validation popup. Since the field is already clearly marked as required and visually highlighted, the risk of accidentally overlooking it is quite low. We would like to hear how others see this in practice. Does the current default feel helpful in your workflows, or would a default of 1 make more sense in everyday use? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 34671] New: Collapsing fields in patron form allows saving without mandatory fields
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34671 Bug ID: 34671 Summary: Collapsing fields in patron form allows saving without mandatory fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've had cases where user has been able to save patron without address. It turned out that if one collapses patron entry fields validating those fields no longer works even if they are marked as mandatory. To reproduce: 1. Make sure you have "Main address" fields set as mandatory with BorrowerMandatoryField syspref (address, city, zipcode) 2. Add new patron, fill in some info, but leave "Main address" fields empty. 3. Attempt to save. => "This field is mandatory" should be displayed next to the address fields. 4. Collapse "Main address" section. 5. Attempt to save again. => Patron is saved successfully without address information. I'm using address section as an example here, but this happens with every other fields as well. I was able to save patron without surname and date of birth this way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198664|0 |1 is obsolete| | --- Comment #50 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 198751 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198751&action=e… Bug 6532: Way to move items to another record in batches This patch adds a new "Move items in a batch" feature, allowing to move multiple items from one bibliographic record to another in a single operation. Test plan: 1. Apply the patch and restart_all. 2. Open a record with at least 2 items (record A). Open or create a second record (record B). 3. On record A: Edit -> "Move items in a batch". Select 1 item, enter record B's biblionumber, submit. => Job finishes. The item appears on record B, not on record A. 4. Repeat with "Delete source bibliographic records if no items remain" checked and move the last item of record A. => Job finishes. Record A is deleted. 5. Place a biblio-level hold on a record with 2 items (record C). Go to Edit -> "Move items in a batch". => A warning icon appears on each item explaining that biblio-level holds will follow if no items remain. 6. Move only 1 item of record C to record B. => The biblio-level hold stays on record C (still has 1 item). 7. Move the last item of record C to record B. => Job report warns that the biblio-level hold has been automatically transferred to record B. => Confirm: record B now has the hold, record C has none. 8. You can test also with hold at item level. Hold simply follows the item on the new record linked. 9. Try entering a non-existent biblionumber as destination. => Error shown before the job is enqueued. Sponsored-by: Université Côte d'Azur Current status: Signed Off -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0