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

[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

[Bug 39884] New: NOTIFY_MANAGER notice only sends when editing manager from an individual suggestion
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39884 Bug ID: 39884 Summary: NOTIFY_MANAGER notice only sends when editing manager from an individual suggestion Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org You can notify a manager with the NOTIFY_MANAGER, when they become the manager of a given suggestion. This only works when editing an individual suggestion where you can check the 'Notify manager' checkbox. Staff can also update the suggestion manager from the main suggestions page, but when you do so there is no option to notify the manager. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 26553] New: Datatables button code is duplicated
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26553 Bug ID: 26553 Summary: Datatables button code is duplicated Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Code in prog/js/datatables.js and columns_settings.inc have both the (almost) same code for buttons. Can we avoid that? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 141

[Bug 42425] New: Add checkin_id FK to accountlines to link fee adjustments to checkin events
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42425 Bug ID: 42425 Summary: Add checkin_id FK to accountlines to link fee adjustments to checkin events 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: 42418 Blocks: 24401 When AddReturn processes a checkin, it may create or modify several accountlines (lost item fee refunds/charges, processing fee refunds, etc.). Currently these fee adjustments have no persistent link back to the checkin event that triggered them. Bug 42418 introduced the checkins table as a first-class resource. Adding a checkin_id FK to accountlines would: - Allow Koha::Checkin->account_lines as a proper relationship - Enable embedding account_lines in the checkin REST API response (bug 24401) - Provide an audit trail linking financial transactions to the specific checkin that caused them - Eliminate the need to infer fee changes from timestamps or $messages parsing Implementation notes: - Add checkin_id INT(11) DEFAULT NULL to accountlines with FK to checkins.checkin_id ON DELETE SET NULL - Update AddReturn to pass the checkin_id when creating/modifying accountlines during return processing - The relevant C4::Circulation code paths are: _FixAccountForLostAndFound, _FixOverduesOnReturn, and the lost item fee charge logic Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24401 [Bug 24401] REST API: Check-in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42418 [Bug 42418] Add Koha::Checkin(s) - checkin as a first-class resource -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23