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

[Bug 11999] Add two checks in CanBookBeReserved and CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11999 --- Comment #145 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- In CanBookBeReserved : my $holds = $patron->holds; In my opinion we should avoid this var an call like in CanItemBeReserved : $patron->holds->count >= $maxreserves -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42186] New: Add more fields to patron search
by bugzilla-daemon＠bugs.koha-community.org 07 May '26

07 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42186 Bug ID: 42186 Summary: Add more fields to patron search 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: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The patron search results table shows fields like amount of checkouts and fines. But you can't search for those fields from the patron search. We should add at least the fields that are displayed in the results table anyway into the patron search. Also it would be nice to search some fields as a date range, e.g. wanting to find patrons from a certain age to a certain age. So for instance, in the range from dateofbirth >= X to dateofbirth <= Y. Or to find patrons with an expiry date in a certain range. Like "whose cards expired more than three years ago". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

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

06 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 ---------------------------------------------------------------------------- Blocks| |42541 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42541 [Bug 42541] Add order and serial controls before moving items -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

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

06 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 ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42541 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 42538] New: Patron account expiry message preference is shown and editable when creating new patron in category for which expiry notice is enforced
by bugzilla-daemon＠bugs.koha-community.org 06 May '26

06 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42538 Bug ID: 42538 Summary: Patron account expiry message preference is shown and editable when creating new patron in category for which expiry notice is enforced Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Depends on: 30301 To recreate: - edit a patron category to set 'Enforce patron account expiry notice' to Yes - create a new patron in that category - confirm that the expiry notice messaging preference is visible and editable in the patron creation screen - save your patron - confirm once the patron is created you can no longer see the account expiry notice in the messaging preferences while viewing or editing your patron If the intent here is to prevent any changes to this preference for patrons in the category, we should not be able to change the preference at creation. As suggested in Bug 40646, we could show the preference, have it enabled, and prevent changes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30301 [Bug 30301] Add an option to specify the patron expiration notices as mandatory by patron category -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

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

06 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #49 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Hello, As Mathieu said, I need to clarify a particular behaviour : Before this patch, when we perform an action to attach an item, if all items of a hold biblio were moved, the hold remained linked to the biblio; however, if that biblio was deleted, the hold would disappear. This fix changes the behaviour by moving the hold to the destination record provided that the last item has been moved. As this patch has now been signed off, I’d like to clarify the change in behaviour. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

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

06 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 #198318|0 |1 is obsolete| | Attachment #198319|0 |1 is obsolete| | Attachment #198320|0 |1 is obsolete| | Attachment #198321|0 |1 is obsolete| | Attachment #198322|0 |1 is obsolete| | Attachment #198323|0 |1 is obsolete| | Attachment #198324|0 |1 is obsolete| | --- Comment #48 from Thibaud Guillot (thibaud_g) <thibaud.guillot(a)biblibre.com> --- Created attachment 198664 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198664&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 the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 42536] New: ERM Resource proxy should be displayed
by bugzilla-daemon＠bugs.koha-community.org 06 May '26

06 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42536 Bug ID: 42536 Summary: ERM Resource proxy should be displayed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk The proxy field of an ERM Resource record should be displayed in the record view under Resource settings (like Coverage dates) To reproduce: - Create an ERM Package - Create an ERM Title - Modify the title and link it to the package. Enter Start date and Proxy - Save - Display Title view - Click on Linked package in the table below Now you see the resource record in the view mode: cgi-bin/koha/erm/eholdings/local/resources/123 Verify, that proxy is not displayed, only the start date. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 42496] New: Holds to pull causes virtual keyboard to flicker when using filters on Android tablets
by bugzilla-daemon＠bugs.koha-community.org 06 May '26

06 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42496 Bug ID: 42496 Summary: Holds to pull causes virtual keyboard to flicker when using filters on Android tablets Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Holds to pull view causes Android devices' virtual keyboard to flicker many sequential times (sometimes more than 10) specifically when filtering by text field filters on Android tablets. The flickering happens when you activate a filter field. Tested on latest Firefox version on an Android tablet Running Koha 25.05. By flickering I mean the virtual keyboard getting brought up (popping up) and instantly going down in a repeated sequence. The number of times it happens seems to depend on what filter you press on and how much data is being viewed in the datatable. This is an accessibility issue that should be fixed asap since many libraries use holds to pull report on tablets for pulling holds "at location". I tried to hunt for similar bugs reported in other parts of Koha but couldn't find any. I've also verified that this issue exists on a 2022 model Google Pixel using Chrome with desktop mode/view and in mobile mode/view. Many other handheld Android devices have this issue too I assume and it doesn't seem to be browser specific or browser version specific. Haven't tested on an IPad. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40340] New: Backslashes next to a subfield ($) breaks staging
by bugzilla-daemon＠bugs.koha-community.org 06 May '26

06 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40340 Bug ID: 40340 Summary: Backslashes next to a subfield ($) breaks staging Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: enica(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 183951 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183951&action=e… Test MARC file If you have a backslash next to a subfield in the data, the staging will fail if you are using the tag as a record matching rule. Most commonly, matching on 245$a (title or title-cover). For instance, in the attached file, there is a backslash right before $h =245 00$aKnights of the black earth \$h[Book] If you have 245 as matching rule, the import batch will fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17