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

[Bug 43644] New: Show the vendor name instead of ID in booksellers.pl breadcrumb
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43644 Bug ID: 43644 Summary: Show the vendor name instead of ID in booksellers.pl breadcrumb 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: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Show the vendor name instead of ID in booksellers.pl breadcrumb /cgi-bin/koha/acqui/booksellers.pl?booksellerid=1 Currently showing the vendor id. Reason for Change: Librarians identify vendors by name, not internal primary keys (booksellerid). Expected Result: The breadcrumb trail on booksellers.pl should display the vendor name (e.g., "Vendors > Search for vendor: [Vendor Name] instead of raw numeric IDs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 43886] New: Renewal messaging is confusing when renewal override settings conflict
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43886 Bug ID: 43886 Summary: Renewal messaging is confusing when renewal override settings conflict Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- We currently have three system preferences that control whether staff can or cannot override various types of renewal blockers: AllowFineOverrideRenewing AllowRenewalLimitOverride AllowRenewalOnHoldOverride However, the checkouts table only displays one relevant status about whether an item is renewable, even if there are multiple statuses that affect the item's renewability. If a checkout has multiple statuses that block renewal, including a mix of statuses that can be overridden and statuses that cannot be overridden, the messaging and behavior of that checkout can be confusing. Example scenario: 1. Set the following system preference values: AllowRenewalLimitOverride - allow AllowRenewalOnHoldOverride - don't allow 2. Find a biblio record with only one item and check that item out to Patron A 3. Create or edit an appropriate circulation rule to set "Renewals allowed (count)" to 0 4. Place a hold for Patron B on that biblio record 5. Go to Patron A's details page, and click the "Override renewal restrictions" checkbox at the bottom of their checkouts list --> Notice that a renewal checkbox appears next to the checkout, and the renewal status says "Not renewable (0 of 0 renewals remaining)", making no mention of Patron B's hold which should block renewal 6. Check the checkbox and try to renew it anyway --> The item's renewal column now says the renewal failed due to it being on hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 30328] New: Add ability to generate barcode with branch specific prefix
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30328 Bug ID: 30328 Summary: Add ability to generate barcode with branch specific prefix Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We should add more flexibility to generating barcodes by letting libraries define branch specific prefix for their barcodes. For this we need to add new barcode option to syspref "autobarcode" and new systempreference where prefixes are set. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49

[Bug 42325] New: Minor corrections for accuracy in error messages and comments in AuthUtils
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42325 Bug ID: 42325 Summary: Minor corrections for accuracy in error messages and comments in AuthUtils Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonadab.theunsightlyone(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Created attachment 196995 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=196995&action=e… Patch: correct error message (about non-positive length) and a couple of comments, for accuracy. In the course of familiarizing myself with the codebase, I ran into a couple of rather minor things that could stand to be fixed up. I have published a branch here: https://github.com/tsadok/Koha/tree/fixes So far, it only has one commit (which only touches one file), here: https://github.com/Koha-Community/Koha/commit/d5ea3ec7fa35b25cb14a6b60c8ddd… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42044] New: Automatically update LDR/5 for modified records
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42044 Bug ID: 42044 Summary: Automatically update LDR/5 for modified records Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org According to https://loc.gov/marc/bibliographic/bdleader.html, the 5th byte of the leader, Record status, could/should be system generated: "System-Generated Elements - Following Leader elements are usually system generated: [...] 05 Record status" Same for authority records. At present, Koha does not automatically update LDR/5 after a record has been modified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 43380] New: Koha will generate spurious print notices if itiva is enabled and a patron has only selected phone notices
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43380 Bug ID: 43380 Summary: Koha will generate spurious print notices if itiva is enabled and a patron has only selected phone notices Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- If a patron only has itiva notices enabled ( and possibly sometimes with other transports enabled, depending on sorting ), Koha will always generate a print notice for them. Take this excerpt from Reserves.pm: 2086 while ( my ( $mtt, $letter_code ) = each %{ $messagingprefs->{transports} } ) { 2087 if ( 2088 ( $mtt eq 'email' and not $to_address ) # No email address 2089 or ( $mtt eq 'sms' and not $patron->smsalertnumber ) # No SMS number 2090 or ( $mtt eq 'itiva' 2091 and C4::Context->preference('TalkingTechItivaPhoneNotification') 2092 ) # Notice is handled by TalkingTech_itiva_outbound.pl 2093 or ( $mtt eq 'phone' and not $patron->phone ) # No phone number to call 2094 ) 2095 { 2096 unless ($notification_sent) { 2097 $notification_sent++; 2098 &$send_notification( 'print', 'HOLD' ); 2099 } 2100 next; 2101 } 2102 2103 &$send_notification( $mtt, $letter_code, $messagingprefs->{wants_digest} ); 2104 } 2105 } Lines 2090/2091 will always be true if itiva is enabled. If the patron has only itiva enabled ( or itiva happens to be the first transport handled in the loop ), the value check at line 2096 will always be false, and thus the call to send_notification for the print version will be triggered at line 2098. It seems that we should replace lines 2090/2091 with something like: or ( ( $mtt eq 'itiva' and !C4::Context->preference('TalkingTechItivaPhoneNotification') ) or ( $mtt eq 'itiva' and not $patron->phone ) ) so if they are to be sent an itiva notice but itiva is not enabled, or itiva *is* enabled but they don't have a voice phone number set, *then* send the print notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 35288] New: ApplyFrameworkDefaults add plugin to add more fine grained defaults handling
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35288 Bug ID: 35288 Summary: ApplyFrameworkDefaults add plugin to add more fine grained defaults handling Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)trust-box.at QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The "new" ApplyFrameworkDefaults option is to coarse sometimes ie quite often you also want to apply default values even if then field wasn't empty before e.g. on duplicating a new controlnumber should be generated etc so I suggest (and already wrote) a new plugin hook (see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33669) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 40860] New: ILL get_notice does not consider HTML template notices
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40860 Bug ID: 40860 Summary: ILL get_notice does not consider HTML template notices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com ill_full_metadata => $metastring has the attributes joined by a "\n". This does not work if the notice is an HTML notice. For HTML notice, a '<br>' needs to be used instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42623] New: Add ability to restrict which libraries can be selected in a report runtime parameter
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42623 Bug ID: 42623 Summary: Add ability to restrict which libraries can be selected in a report runtime parameter Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Currently, if a report contains a runtime parameter for Library any user can select any library. This is at odds with work in BZ 16631 and BZ 42621 to allow restriction of data access by library & group. We would like to establish a way to denote in a report that a Library runtime parameter should either default to the user's library or allow selection of only libraries within that user's library group. This work should make sure to enforce these limits at the controller level as well so users cannot circumvent the limit by manually editing a report URL. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 43883] New: Allow custom OPAC pages to require login
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43883 Bug ID: 43883 Summary: Allow custom OPAC pages to require login Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- It would be helpful is custom OPAC pages created in the Tools module could be set to require the user to be logged in. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1