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

[Bug 43547] New: Update and Run SQL button runs report before updating
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43547 Bug ID: 43547 Summary: Update and Run SQL button runs report before updating Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- To recreate: - save and run a report "SELECT * FROM items LIMIT 1" - confirm you are shown 1 item - edit report, change your limit to 2 - click Update and run SQL - confirm you are shown just 1 item - click Show SQL code, confirm it still shows "LIMIT 1" - click Run report - page reloads, now shows 2 items -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43150] New: Deleting holidays on range may sometimes delete too many holidays
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43150 Bug ID: 43150 Summary: Deleting holidays on range may sometimes delete too many holidays 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Noticed while working on bug 24782. When modifying holidays on range sometimes those modifications would seep into other holidays that aren't on given timeperiod. Tested some more and this can also happen with deleting holidays on range too. This really tricky to reproduce and it doesn't occur all the time, but here's one way to make this happen. 1. Make sure you have plack running. 2. Create three single holidays on a range. 3. Now delete last two of the just added holidays, use " Delete the single holidays on a range." tool. => Note that all holidays were deleted. => Add holidays for different timeperiods and delete them, note how deleting may affect holidays out of given timeperiod. We had a same problem with adding new holidays and it was fixed on bug 38357. This seems to be a same problem, @holiday_list is not reseted to an empty array so previously created/deleted/modif holidays are never cleared from plack workers memory. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 Cab Vinton <bibliwho(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|bibliwho(a)gmail.com | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43504] New: Extract Koha::Account->forgive_debit from _FixOverduesOnReturn
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43504 Bug ID: 43504 Summary: Extract Koha::Account->forgive_debit from _FixOverduesOnReturn 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: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- In preparation for bug 39756, extract Koha::Account->forgive_debit from _FixOverduesOnReturn. The new method is also independent from userenv. This patch is also to do with bug 39756 not calling either LostItem or the methods it calls (in this case, _FixOverduesOnReturn) so that it is compatible with the trigger-based circulation rules around long overdue processing 39756 introduces. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43622] New: Advanced cataloguing editor (cataloguing/editor.pl) loads RequireJS and can conflict with plugins
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43622 Bug ID: 43622 Summary: Advanced cataloguing editor (cataloguing/editor.pl) loads RequireJS and can conflict with plugins Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- The "Ask the manual" plugin generating JS errors on the advanced editor view: Uncaught ReferenceError: docsearch is not defined <anonymous> http://dev-intra.localhost/api/v1/contrib/ask_the_manual/static/static_file… EventListener.handleEvent* http://dev-intra.localhost/api/v1/contrib/ask_the_manual/static/static_file… Uncaught TypeError: TextMARC.RecordToText is not a function Note that I fixed that in the plugin already but that may affect other plugins https://gitlab.com/joubu/koha-plugin-ask-the-manual/-/commit/5b53927ef2db5f… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 40832] New: Display MARC 382 (Medium of Performance) on result list and detail page
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40832 Bug ID: 40832 Summary: Display MARC 382 (Medium of Performance) on result list and detail page Change sponsored?: --- Product: Koha Version: unspecified 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: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org Libraries specializing in musical works consider MARC field 382 (medium of performance) important to be visible on the detail and search result views. https://www.loc.gov/marc/bibliographic/bd382.html This Bug aims to add support to displaying this field both on OPAC and the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 43617] New: COUNTER 5.1 SUSHI parser drops usage data when a Report_Item has multiple Attribute_Performance entries
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43617 Bug ID: 43617 Summary: COUNTER 5.1 SUSHI parser drops usage data when a Report_Item has multiple Attribute_Performance entries Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com 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 Target Milestone: --- Hello, COUNTER 5.1 introduced Attribute_Performance, an array nested inside a single Report_Item. A platform or database that serves several content types gets several entries in this array for the same Report_Item. So I tried to fix that with the following patch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 38336] New: Confusion between 099 and 942 field in UNIMARC framework
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Bug ID: 38336 Summary: Confusion between 099 and 942 field in UNIMARC framework Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I believe there is something wrong in UNIMARC default framework (https://github.com/Koha-Community/Koha/blob/main/installer/data/mysql/en/ma… ) We have 2 fields for "local" data (specific to Koha) at biblio level : 099 and 942 And the same pieces of information are present in subfields of both fields : - 099$x and 942$0 (Number of issues => biblioitems.totalissues) - 099$s and 942$s (Serial record => biblio.serial) - 099$t and 942$c (Koha item type => biblioitems.itemtype) I suppose it is an error, because it makes no sense... And note that the 099 field in UNIMARC framework is called "local dates", so it should not contain information about item type or number of issue. Do you think we could remove safely from the default templates 099$x, 099$s, 099$t ? I don't know if those values may be harcoded somewhere in the code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 77

[Bug 43383] New: problem adding to list or cart when using browser's back button
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43383 Bug ID: 43383 Summary: problem adding to list or cart when using browser's back button Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface 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 Target Milestone: --- To recreate: 1. Do a catalog search that brings up multiple results 2. Check the checkbox of in the left column for the first two results 3. Click on the title of the 3rd result to take you to the details page for that item 4. Use the borwser's back button to return to the search results 5. Notice the first 2 titles are still checked. 6. Now check the 3rd result and click 'Add to list' 7. Only the 3rd title is added, even though all 3 are checked. 8. Try steps 1 - 7 again but with 'Add to cart', same behavior. 9. Try setps 1 - 7 again but with 'Place hold', all 3 items are selected. I get this behavior in both Chrome and Firefox. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 42608] New: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Bug ID: 42608 Summary: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode is set to Dayweek, the pickup expiration date set for a hold by Koha::Hold::set_waiting is inflated by a whole week whenever the pickup window crosses a single (one-off) closure on a normally-open weekday -- for example a Bank Holiday Monday. Steps to reproduce ================== System preferences: ReservesMaxPickUpDelay = 6 ExcludeHolidaysFromMaxPickUpDelay = ON ExpireReservesOnHolidays = ON useDaysMode = Dayweek Branch calendar: - Sundays marked as a weekly closed day. - A single (one-off) holiday on a Monday two weeks out -- for example 2026-05-04 (the early May Bank Holiday). Trap a hold to waiting at that branch on Tuesday 2026-04-28. Actual result ============= expirationdate is set to 2026-05-12 -- a 14-day pickup window. Expected result =============== expirationdate should be 2026-05-06 -- a 6-open-day pickup window. The intent of ExcludeHolidaysFromMaxPickUpDelay is to give the patron the full ReservesMaxPickUpDelay count of *open* days to come and collect the item, by extending the window by one calendar day for every closed day that falls inside it. useDaysMode (Dayweek / Datedue / Calendar / Days) is a loan-due-date concept -- the patron picks no weekday for a hold pickup; staff trap the item, and the only thing that should influence the expiration date is how many open days the patron should get to collect. Wider example table =================== Same configuration as above. Sunday 3 May and Monday 4 May 2026 are closed at the branch. Comparison of current (buggy) vs expected expiration dates for each weekday a hold could be trapped that week: Hold trapped on Current (buggy) Expected ----------------- ----------------- ----------------- Mon 27 Apr 2026 Mon 11 May 2026 Tue 5 May 2026 Tue 28 Apr 2026 Tue 12 May 2026 Wed 6 May 2026 Wed 29 Apr 2026 Wed 13 May 2026 Thu 7 May 2026 Thu 30 Apr 2026 Thu 14 May 2026 Fri 8 May 2026 Fri 1 May 2026 Fri 15 May 2026 Sat 9 May 2026 In each case the expected expiration is `waitingdate + ReservesMaxPickUpDelay` open days, with Sun 3 May and Mon 4 May skipped (not counted toward the 6-day window). The current buggy expirations are all 14 calendar days from the trap date -- a whole extra week. Reproduction snippet ==================== use Koha::Calendar; use Koha::DateUtils qw(dt_from_string); # Test branch: Sundays weekly closed, single holiday 2026-05-04. my $cal = Koha::Calendar->new( branchcode => 'BR', days_mode => 'Dayweek', ); # Bug: prints 2026-05-12 (14 days). # Expected: 2026-05-06 (6 open days). say $cal->days_forward( dt_from_string('2026-04-28'), 6 )->ymd; Notes ===== Loan due dates calculated by Koha::Calendar::addDays under useDaysMode=Dayweek behave correctly -- the bug only surfaces on hold pickup expiration dates. A fix should not regress the loan due-date behaviour, which is the original purpose of the Dayweek mode (keeping a Friday-due loan due on a Friday over closures). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22