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

[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

[Bug 42013] New: Confirmation dialog for "Remove all reserves" never shown on course details page
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42013 Bug ID: 42013 Summary: Confirmation dialog for "Remove all reserves" never shown on course details page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org On the course details page (course_reserves/course-details.tt), clicking "Remove all reserves" skips the confirmation dialog and immediately submits the form. The "Remove all reserves" button (#rm_items_button) is an <a> tag separate from the #rm_items form. The click handler on the button calls $("#rm_items").submit() programmatically. A separate $("#rm_items").click(...) handler was intended to show a confirmDelete dialog, but it is bound as a click event on the form element, which is never clicked by the user. jQuery's .submit() method also does not trigger click events, so the confirmation is never shown. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 38948] New: Modal error on some pages: Can't access property "backdrop"
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38948 Bug ID: 38948 Summary: Modal error on some pages: Can't access property "backdrop" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 35402 I know I've seen this in more than one place, but I've just confirmed that it appears in the console on the item add/edit page: Uncaught TypeError: can't access property "backdrop", this._config is undefined _initializeBackDrop http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.1… On http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.1… <anonymous> http://127.0.0.1:8081/intranet-tmpl/prog/js/cookieconsent_24.1200003.js:20 <anonymous> http://127.0.0.1:8081/intranet-tmpl/prog/js/cookieconsent_24.1200003.js:197 bootstrap.bundle.min_24.1200003.js:6:52582 I think it's new since the Bootstrap 5 upgrade. Some web searches turn up information like "The problem is that the Modal has not been loaded into the DOM at this stage and therefore is undefined when the getElementById action is performed. The solution was to wait until the DOM is loaded." This would make sense considering the add/edit item page is one of those pages where the JS is loaded at the top of the page rather than the bottom. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 [Bug 35402] Update the OPAC and staff interface to Bootstrap 5 -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 43077] New: Add encode_claims/decode_claims to Koha::Token
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43077 Bug ID: 43077 Summary: Add encode_claims/decode_claims to Koha::Token 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 42383 Target Milestone: --- Koha::Token currently only supports JWTs with a single 'id' claim (generate_jwt/check_jwt/decode_jwt). This adds general-purpose encode_claims/decode_claims methods that support arbitrary claim hashes, and refactors the existing id-based methods as thin wrappers on top. This will be used by the upcoming Koha::Module::Policy classes (Bug 42383) which serialize per-module capability hashes as JWTs in API response headers. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42383 [Bug 42383] Migrate check-in page to Vue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 8589] Advanced Search for itemtype and location produces some results that are not useful
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8589 Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- *** This bug has been marked as a duplicate of bug 42835 *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8589] Advanced Search for itemtype and location produces some results that are not useful
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8589 --- Comment #13 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Apologies for the overlap.. bugzilla has an awful lot of duplicates these days :( I'd love to see a comparison of how you approached it compared to the submissions on that tree of bugs (the first just adds the index, there are dependent one's that expose additional functionality). I'm sure we could learn from each other and working as a team might get the work over the line.. I want to make sure we're satisfying everyone's needs and I'm sure we'de be happy to add co-authorship to the commit series and bugs if you end up contributing to it to bring it up to parity. Many thanks -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43517] New: Enable vue-tsc type checking and shared Cypress component-test shims
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43517 Bug ID: 43517 Summary: Enable vue-tsc type checking and shared Cypress component-test shims Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 41129 Target Milestone: --- This patch enables vue-tsc type checking for .vue files project-wide, and adds shared Cypress component-test environment shims that any future Vue component test can rely on. Specifically: - tsconfig.json: target the language level rspack/swc actually emit (ES2020), and let JSDoc types in .js files flow into type checking. - eslint.config.mjs: parse <script> blocks in .vue files with the TypeScript parser. - package.json: bump typescript and add vue-tsc as a dev dependency. - vue/ambient.d.ts: ambient module declarations for third-party libraries that ship without their own types (flatpickr, bootstrap Modal, vue-select), and for CSS side-effect imports. - t/cypress/support/console-hooks.js: shared hooks (used by both e2e and component tests) that make console.warn throw so real warnings fail tests fast, and that fail DataTables warnings logged via console.log. - t/cypress/support/component.ts: mirror the globals normally provided by page-level includes (window.dayjs, window.flatpickr with Koha's defaults, window.$timezone(), String.prototype.format) so components that depend on them can mount in isolation, and wire in the new console-hooks. None of this is feature-specific; it's split out from bug 41129 (booking workflows) because it benefits from independent review and several later patches depend on it. Test plan: 1. Run: yarn tsc --noEmit (or the project's vue-tsc check script) and confirm it passes with no new errors. 2. Run the full Cypress component suite and confirm nothing regresses. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 [Bug 41129] Migrate place_booking.js to a Vue island. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 12620] Proxy Add-on for Koha z39.50/SRU servers
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12620 --- Comment #22 from Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> --- Hi David, Thanks for catching this in comment #18 — koha-conf.xml is clearly a stronger boundary than a system preference, so I've gone ahead and made the change. Attached three patches (the first obsoletes 201633, which is the same base fix just rebased): * Bug 12620: Proxy Add-on for Koha z39.50/SRU servers — the base patch, rebased onto current main. * Bug 12620: (follow-up) Move HttpForwardProxy from a system preference to koha-conf.xml — removes the syspref entirely (sysprefs.sql, web_services.pref, the atomicupdate), adds a documented http_forward_proxy entry to koha-conf.xml, and updates C4::Breeding::_create_connection / admin/z3950servers.pl / z3950servers.tt to read it from C4::Context->config instead of Koha.Preference. The per-server do_not_use_proxy checkbox/column is unchanged. * Bug 12620: (QA follow-up) Add test coverage for http_forward_proxy — _create_connection had no test coverage at all for the proxy branch, for either the syspref or the config version. Added 4 assertions mocking ZOOM::Connection::connect and C4::Context->config. Tested manually too: without http_forward_proxy set, the checkbox doesn't show and there's no proxy attempt; with it pointed at a local Squid allowing CONNECT to port 210, a real Z39.50 search tunnels through it (confirmed in Squid's access log); with "Do not use proxy" checked, the connection goes direct. One thing for the record, not to argue against making the change — koha-conf.xml is the right call either way: HttpForwardProxy as a syspref was already gated behind the parameters permission, not editable by just any logged-in user. The real difference is "staff with syspref admin rights via the web UI" vs "someone with actual server/filesystem access", which is a meaningful drop in blast radius, but it wasn't wide open before either. Worth keeping in mind since staff with syspref access already have plenty of other preferences that could do comparable damage if misused (arbitrary URLs, LDAP config, etc.) — this closes one more of those doors, it's not the only one standing open. Let me know if this addresses your concern or if you'd like anything else changed before a signoff. Thanks, Adolfo -- You are receiving this mail because: You are watching all bug changes.

1 0