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

[Bug 41674] New: Add template plugin for linking to system preferences based on user permission
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41674 Bug ID: 41674 Summary: Add template plugin for linking to system preferences based on user permission 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: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org There are many places in templates where we link to a system preference and we are inconsistent about whether these links are dependent on the permission of the logged-in user. I propose to add a template plugin which handles the permission check. [% "RequireChoosingExistingAuthority" | html | $LinkPref %] For a user with 'CAN_user_parameters_manage_sysprefs' permission it outputs: <a class="link_preference" href="admin/preferences.pl?op=search&ok=Search&searchfield=RequireChoosingExistingAuthority">RequireChoosingExistingAuthority</a> For a user without permission it outputs: <span class="link_preference">RequireChoosingExistingAuthority</span> -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 42978] New: Renewal window
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '26

02 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42978 Bug ID: 42978 Summary: Renewal window Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Target Milestone: --- Should renewals have a window of time (both manual and auto) for renewals, in order to prevent checkout abuse. Consider, you have ManualRenewalPeriodBase set to "the old duedate of the checkout". You check it out, and the patron or staff at some point before it is due hits renewal (either on accident or on purpose). For this scenario, lets say it is done right after checkout. This could effectively work around limits to not renew if the item goes on hold. If the library allows a couple of renewals, this prevents bringing the item back sooner if others are waiting for the item. I haven't seen such a window, but allowing a window of x number of days before and after the due date to renew would make sense, to limit people gaming the checkout period. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42917] New: Error when changing existing hold from item/record level with only place_holds permission
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42917 Bug ID: 42917 Summary: Error when changing existing hold from item/record level with only place_holds permission 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- To recreate: 1/ Create or find a user with place_hold permission but not the top level permission 2/ Place a hold 3/ From reserve/request.pl?biblionumber=X try to change the hold from record to item, or vice versa. 4/ See popup: There was an error:error Forbidden -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 39027] New: News are order with older on top
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39027 Bug ID: 39027 Summary: News are order with older on top Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When a news is created, it is displayed last in the news list at the OPAC. You can change that behaviors by using the field 'Number' to order them manually but then, you have to manually edit all news to add a new one first. -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 42973] New: Additional contents ordering ignores "Appear in position" when sorting news
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42973 Bug ID: 42973 Summary: Additional contents ordering ignores "Appear in position" when sorting news Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 39027 changed the default ordering of news items to use the publication date (newest first). However, this change no longer respects the manual "Appear in position" value (additional_content.number). Previously, libraries could assign a position number to pin or manually order specific news items. After Bug 39027, news items are always ordered by publication date, regardless of whether a manual position has been assigned. To recreate: 1. Create two or more news items. 2. Assign an "Appear in position" value to one of the items (for example, 1). 3. Give another news item a more recent publication date. 4. View the news on the OPAC or staff interface. 5. Notice that the newer item is displayed first instead of the item with the assigned position. Expected behavior: If a news item has an "Appear in position" value, that value should take precedence over the default publication date ordering. News items without a manual position should continue to be ordered by publication date (newest first). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 41445] New: Wrong info about holds selection after hold suspending
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41445 Bug ID: 41445 Summary: Wrong info about holds selection after hold suspending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com After suspending a hold at patron's holds tab, incorrect information about holds selection is displayed. To reproduce: 1. Have unsuspended hold(s). 2. Go to patron's account, "Details" or "Check out", and "Holds" tab. 3. Click "Suspend" button in "Suspend?" column and confirm modal. 4. Notice: 4.1 checked header checkbox (first column) - not correct, checkbox(es) below are not checked 4.2 number of holds selected in line below the holds table - not correct, checkbox(es) above are not checked, buttons "Cancel selected" and "Suspend selected" are active -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 42960] New: Database update 25.12.00.059 attempts Elasticsearch mapping update when SearchEngine is Zebra
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42960 Bug ID: 42960 Summary: Database update 25.12.00.059 attempts Elasticsearch mapping update when SearchEngine is Zebra Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- When upgrading a Koha instance to 26.05, db revision 25.12.00.059 (Bug 40658 - Ensure local-number is sortable) unconditionally instantiates Koha::SearchEngine::Elasticsearch::Indexer and calls update_mappings(). This happens even when the instance has SearchEngine = Zebra. On a Zebra-only instance without Elasticsearch configured, koha-upgrade-schema fails and blocks the entire schema upgrade: Upgrade to 25.12.00.059: Bug 40658 - Ensure local-number is sortable ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_lise_biblios". Reason was: "". Index needs to be recreated and reindexed' Reproduced in koha-testing-docker with KOHA_IMAGE=26.05, SearchEngine=Zebra, by resetting Version to 25.1200058 and setting local-number sort=0. Expected behavior: - The DB revision should still set search_marc_to_field.sort = 1. - Elasticsearch mappings should only be updated if SearchEngine is Elasticsearch. - Zebra-only instances should not require Elasticsearch to complete koha-upgrade-schema. Proposed fix: Guard the Elasticsearch mapping update with: if ( C4::Context->preference('SearchEngine') eq 'Elasticsearch' ) { ... } and report that the ES mapping update was skipped otherwise. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20573] New: Patron receives membership expiry notice but 'will expire soon' alert doesn't show for staff at checkout
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20573 Bug ID: 20573 Summary: Patron receives membership expiry notice but 'will expire soon' alert doesn't show for staff at checkout Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've seen a situation a few times now, where a patron comes into the library and informs the staff that they received notice that their account is going to expire, but when staff go to the patron's account and click checkout, the message, "Attention: Expiration: Patron's card will expire soon. Patron's card expires on ...", doesn't appear. This issue happens when the patron comes into the library exactly 30 days from their expiration. In this case, MembershipExpiryDaysNotice = 30 days and NotifyBorrowerDeparture = 30 days. So for example, the patron's expiration date is 05/11/2018. On 4/11/2018 the patron gets their notice, as expected. They come into the library on 4/11/2018 and the checkout message alerting staff to the impending expiration message doesn't show. Checking the same account on 4/12/2018 shows the message "Attention: Expiration: Patron's card will expire soon. Patron's card expires on 05/11/2018 Renew or Edit Details" on the checkout screen. I would expect the staff to be alerted at checkout on 4/11/2018 since the patron has been notified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 42968] New: 505 MARC field label is missing in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42968 Bug ID: 42968 Summary: 505 MARC field label is missing in the staff interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The staff interface displays the contents of the MARC 505 field but does not display the "Contents:" label that appears in the OPAC. This results in an inconsistency between the OPAC and staff interface and makes it less clear what the displayed information represents. To recreate: 1.Create or locate a bibliographic record with data in the MARC 505 field. 2.View the record in the OPAC. 3.Note that the 505 field is displayed with the "Contents:" label. 4.View the same record in the staff interface. 5.Notice that the 505 field is displayed without the "Contents:" label. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 42235] New: On OPAC messaging preferences page table header contains no text
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '26

01 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42235 Bug ID: 42235 Summary: On OPAC messaging preferences page table header contains no text Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org To recreate: 1. Log into the OPAC 2. Go to "Messaging" 3. The first column's th in the table contains no text. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18