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

[Bug 42423] New: Submit button in patron search from header never submits
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42423 Bug ID: 42423 Summary: Submit button in patron search from header never submits Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com It looks like there's a bug in bug 41040 that prevents any patron search from the header and not just empty searches. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 41767] New: Plack backlog parameter
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41767 Bug ID: 41767 Summary: Plack backlog parameter 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: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org The default request backlog for starman is 1024 request wich seems too large for Koha. When the system is overloaded it will typically take several minutes to recover because of the backlog of mostly stale requests. I suggest we set a much lower default value and expose a configuration parameter. I propose $PLACK_WORKERS * $PLACK_MAX_REQUESTS / 2 as a default value (just guessing). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 42501] New: ILL: The language of requests send to partners should be the preferred language used by libraries, not by patrons
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42501 Bug ID: 42501 Summary: ILL: The language of requests send to partners should be the preferred language used by libraries, not by patrons Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com When sending a ILL-request to another library (in the ILL requests-module) the language of the request-email is formed from patrons preferred language and not by preferred language used by the partner library. I think it would be easier if it would work like this: If you order an inter library loan from a Finnish university library for an English-speaking patron, the base of the ILL_PARTNER_REQ -notice to the library would be in Finnish, according to the preferred language of the Finnish university library. The request would not be using the language used by the patron. Would it be possible to use partner library's preferred language in the ILL_PARTNER_REQ -notices (and not patrons)? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42497] New: Warning on acqui-home.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42497 Bug ID: 42497 Summary: Warning on acqui-home.pl 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In acqui/acqui-home.pl, this returns a warning because depth does not exist: 134 for my $bp ( @{$budgetperiods} ) { 135 my $hierarchy = C4::Budgets::GetBudgetHierarchy( $$bp{budget_period_id}, undef, undef, 1 ); 136 for my $budget ( @{$hierarchy} ) { 137 $$budget{budget_display_name} = sprintf( "%s", ">" x $$budget{depth} . $$budget{budget_name} ); 138 } 139 $$bp{hierarchy} = $hierarchy; 140 } Could not find any reference to {depth} in budgetperiod -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 39422] New: Checkout 'remember for session' override does not handle holds cancellation
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39422 Bug ID: 39422 Summary: Checkout 'remember for session' override does not handle holds cancellation Change sponsored?: --- 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - Place several holds for patron A 2 - Checkout one of the items to Patron B 3 - You get a warning with an option to cancel the hold 4 - Check the cancel button and the remember button 5 - Checkout the rest of the held books 6 - No warnings 7 - Check patron A - only the first hold was cancelled We have situations where a caregiver or relative will pickup the holds for a patron and the libraries would like to see all of the holds cancel - i.e. we need to remember the saved options correctly -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 38425] New: Add links to full texts based on identifiers
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38425 Bug ID: 38425 Summary: Add links to full texts based on identifiers Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org Marc21 allows to add persistent identifiers to `024 7?` by means of subfields `$2` and `$a`. E.g. one could give the DOI of an eBook as ``` 024 7_ $2doi $a 10.000/123.456.789 ``` For `$2` the LoC refers to the list of standard identifiers, that is actually quite long: https://www.loc.gov/standards/sourcelist/standard-identifier.html Currently, it seems Koha creates a link only if there is a URL in `856 4_` which requires duplication of data. Especially of scientific libraries it would be helpful if ids pointing to "well known" services that assign PIDs would also trigger such a display to point the users to the full texts. The most relevant in this context seem to be: - DOI - PMID - PMC - arXiv - handle - urn In other contexts OpenLibrary was also mentioned. -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 37638] New: Link permissions to entry in the manual
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37638 Bug ID: 37638 Summary: Link permissions to entry in the manual Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lauren_denny(a)sil.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Similar to bug 37624, create a link by the permission that takes you to the manual. If applicable, it would also be helpful to put a note by the permission if a system preference is required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 9805] Lost items are un-lost if returned, but not if renewed
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '26

30 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.ca.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acampbell(a)buttecounty.ca.go | |v --- Comment #66 from Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.ca.gov> --- This would be great to see implemented. As others have said, there have been issues where items are renewed, fines are cleared (because the due date is now in the future), but their items are still Long Overdue (Lost). Manually changing the status of the items via the record, checks the items in. If the fines are over the threshold, staff can still override the renewals, even if we tell them don't renew to avoid this issue. If the item is still not returned, DefaultLongOverdueLostValue will take care of reassigning the LOST status. Currently, if a manager needs to renew the item(s), they check the items in to clear the LOST status, then check them back out. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 20844] New: Reset a hold when it is missing after allocation
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 Bug ID: 20844 Summary: Reset a hold when it is missing after allocation Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There currently is no simple way to 'deallocate' a hold if it has gone missing after it is allocated to a patron but before they collect it. This enhancement would work as follows: 1. item is allocated 2. item cannot be located when patron tries to collect it 3. staff member marks item as Lost 4. if hold was originally a bib-level hold, hold reverts from being specific to the missing item, back to a bib-level hold with priority 1. 5. if hold was originally item-level, staff member gets an alert asking whether to cancel or retain the hold 6. (optionally?) a 'lost hold' notice is queued to be sent to the patron This bug is related to the original description of https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19287#c32 and also to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15679 To do it properly, it may require a couple of new settings, something like: LostBibLevelHoldsRevert SendLostHoldNotices -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 150

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '26

29 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19