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

[Bug 42510] New: MEMBERSHIP_EXPIRED notice to compliment MEMBERSHIP_EXPIRY
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42510 Bug ID: 42510 Summary: MEMBERSHIP_EXPIRED notice to compliment MEMBERSHIP_EXPIRY Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org While it's fantastic to have a pre-expiry notice for membership, it would be very helpful to have a secondary notice that is triggered when the membership actually expires. This would logically align with other notices in Koha such as loans that has a pre-overdue as well as overdue notices. It would also be another opportunity to promote Koha's (new) Koha OPAC account renewal process as signposting text could be added, i.e. 'your account has now expired, you can renew your account by...' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40863] New: Search stopped working
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40863 Bug ID: 40863 Summary: Search stopped working Change sponsored?: --- Product: Koha Version: 25.05 Hardware: HP OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: sergeinik(a)tut.by QA Contact: testopia(a)bugs.koha-community.org After updating to Debian 13, search stopped working. koha-rebuild-zebra -v -f library .error retrieving biblio 3896 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3897 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3898 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3899 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3900 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3901 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3902 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3903 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3904 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3905 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3906 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3907 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3908 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3909 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3910 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3911 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3912 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3913 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3914 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3915 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3916 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. .error retrieving biblio 3917 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 778. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 63

[Bug 42436] New: Some system preferences should be read-only
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42436 Bug ID: 42436 Summary: Some system preferences should be read-only Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There are certain system preferences like Version which should be read-only (at least in the web UI). Well, technically the input should probably be "disabled" rather than "readonly", but the effect is that web users can see the preference but not change it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 34472] New: Template Toolkit reference guide needed
by bugzilla-daemon＠bugs.koha-community.org 01 May '26

01 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34472 Bug ID: 34472 Summary: Template Toolkit reference guide needed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org There are no resources that I've been able to find that clearly layout what we can use from Template Toolkit in our notices and slips. We have https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips#Notice_M… and https://wiki.koha-community.org/wiki/Notices_with_Template_Toolkit but neither clearly layout what we can use, and in which slips. These are more generalized guidelines, but if I am referencing some specific elements, it's a guessing game. And I keep coming across things to use I never heard of before, not mentioned anywhere. It would really be helpful if a wiki guide were put together to make this much clearer than it is right now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 31046] New: Floating Rules Based on Collection/Shelving Location
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31046 Bug ID: 31046 Summary: Floating Rules Based on Collection/Shelving Location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: daniel.gaghan(a)pueblolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com PCCLD would like an option for floating rules to be based on the items shelving location or collection. This is how it would work. 1. A system preference allows for an Authorized Value/Shelfing Location or Collection to restrict floating. 2. The Western Research (Library A) location is added to the system preference and all material with the value does not float. 3. Item is cataloged with the Western Research shelving location. 4. Item is checked-out by a user at Library A. 5. The item is returned to Library B. 5. A message appears in Koha stating the item needs to return to Library A because it does not float. -Daniel -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 39643] New: Add flag to delete access files in cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39643 Bug ID: 39643 Summary: Add flag to delete access files in cleanup_database Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Libraries may find it helpful to be able to delete old access files automatically if a flag were added for this purpose in the cleanup_database.pl cron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24035] New: When recording local use, there is no alert for holds
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24035 Bug ID: 24035 Summary: When recording local use, there is no alert for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com One way of recording local use is through a statistical patron. Checking an item out to a statistical patron records a local use but does not actually check the item out. However, if the item is on hold, there is no indication that it is so, since the item doesn't go through the checkout process. But since the staff is already processing the item to scan it for local use, I feel like it would be logical to alert them that there is a hold on this item. To reproduce: 1- Create a statistical patron category 1.1- Go to Administration > Patron categories 1.2- Create a new patron category 1.3- Fill in the code, description and expiry date 1.4- In the 'Category type' field, choose 'Statistical' 1.5- Save 2- Create a patron of that category 3- Place a hold on an item (for another patron) 4- Check out the item to the statistical patron => It says 'Local use recorded' but there is no pop-up saying the item is on hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 36013] New: update_totalissues.pl should not log
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36013 Bug ID: 36013 Summary: update_totalissues.pl should not log Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Even when CataloguingLog is on, misc/cronjobs/update_totalissues.pl should not log the changes. It is useless and takes database space. Do like bulkmarcimport.pl : https://git.koha-community.org/Koha-community/Koha/src/branch/23.11.x/misc/… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 42507] New: Recall pickup slip popup blocked by browser after 'Print slip and confirm' is clicked on recall modal
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42507 Bug ID: 42507 Summary: Recall pickup slip popup blocked by browser after 'Print slip and confirm' is clicked on recall modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Depends on: 42505 The recall print-slip flow has the same browser popup-blocker problem fixed for hold slips in bug 42505. In koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt the .print-recall click handler sets a hidden recall_slip=1 input and submits the form. circ/returns.pl reads that param and sets the recall_slip template variable on the response page. The response page then calls Dopop('/cgi-bin/koha/recalls/recall_pickup_slip.pl?recall_id=...') from \$(document).ready (via 'if (recall_slip) Dopop(...)') â long after the user gesture has expired. Modern browsers block that window.open() as an unsolicited popup. The recall is confirmed but the slip never appears. Reproduction ============ 1. Place a recall on an item (RecallsEnabled etc. configured). 2. Check in the item; the 'Recall found' modal appears. 3. Click 'Print slip and confirm' (the .print-recall button). 4. Expected: recall is confirmed and the recall pickup slip opens in a new window. 5. Actual: the recall is confirmed but the slip popup is blocked by the browser. Suggested fix ============= Mirror the bug 42505 approach: open the recall pickup slip synchronously inside the .print-recall click handler using the recall_id available in the form, so the window.open() remains tied to the user gesture. Then submit the form to confirm the recall. This avoids the document.ready Dopop chain and the popup blocker. Depends on bug 42505 to keep the fixes consistent. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 [Bug 42505] Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42506] New: Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42506 Bug ID: 42506 Summary: Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Depends on: 42505 With HoldsAutoFill = "Do" and HoldsAutoFillPrintSlip = "Do", a check-in that traps a hold for another branch silently confirms the hold and places the item in transit. The hold transfer slip is then meant to open automatically. The slip is opened via Dopop() / window.open() called from $(document).ready on the response page (koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt, near the 'if (print_slip)' block). Because that window.open() runs after a fresh page load and is not associated with a user gesture, modern browsers commonly block it as an unsolicited popup. The hold is confirmed, the item is in transit, but the librarian sees no slip. This is the auto-fill counterpart to bug 42505. Bug 42505 fixes the manual click path by opening the slip synchronously in the .print click handler. The auto-fill path has no click handler to attach to, so it needs a different solution. Possible approaches =================== 1. Render an inline 'Print slip' button (or banner with a button) on the response page when print_slip is set, and let the librarian click it to open the slip. The user gesture then drives window.open() and is not blocked. 2. Render the slip inline on the response page, perhaps inside an iframe, and trigger window.print() from inside that iframe. 3. Stop using window.open() for the slip and switch to a same-window print mechanism using a hidden iframe + content.print(). Reproduction ============ 1. Set HoldsAutoFill = "Do" and HoldsAutoFillPrintSlip = "Do". 2. Place a hold for a patron with a pickup branch different from the staff member's logged-in branch. 3. Check in the item at the staff member's branch. 4. Expected: hold is auto-confirmed, item placed in transit, slip opens in a new window. 5. Actual: hold is auto-confirmed and item placed in transit, but the slip popup is blocked by the browser. Depends on bug 42505 because the chosen approach for one path may inform the other (the manual click fix in 42505 keeps Dopop()/window.open() but moves it inside the gesture; this auto-fill path may need a more fundamental change away from that pattern). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 [Bug 42505] Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0