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

[Bug 37203] New: Add a booking is ready to collect notice to let patrons know that their booking is ready to be collected
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37203 Bug ID: 37203 Summary: Add a booking is ready to collect notice to let patrons know that their booking is ready to be collected Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, koha-bugs(a)lists.koha-community.org, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 29002 Blocks: 36666 A parallel to the hold ready to collect notice, but for bookings. Once a booking is fully prepared and ready we should notify the patron that they may come and collect it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36666 [Bug 36666] Bookings needs some slips and notices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. You are on the CC list for the bug.

1 13

[Bug 38165] New: Add a view to the staff interface to manage bookings of a library
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38165 Bug ID: 38165 Summary: Add a view to the staff interface to manage bookings of a library Change sponsored?: --- 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: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment there's no real overview of all bookings in the staff interface. The goal of this bug is to provide one that lets staff modify and cancel bookings as well as transforming them into checkouts. I think a good place for this would just be another section under the Circulation section of the staff interface. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 36669] New: Add ability to charge for bookings
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36669 Bug ID: 36669 Summary: Add ability to charge for bookings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 29002 One can charge for reservations, we'd like to also add the option for charging for bookings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 40906] New: Change the "Create report from mana" interface, to make it look more like a plugin market place/app store
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40906 Bug ID: 40906 Summary: Change the "Create report from mana" interface, to make it look more like a plugin market place/app store Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: elias.lorgnier(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: alex.arnaud(a)biblibre.com The idea is to create a better interface than search only for importing reports from mana. A marketplace would allow discovering new reports, while maintaining a good searchability. The information presented as a grid of cards would allow seeing immediately informations that are important to evaluate the relevance and "reliability" of a report : title, description, author, number of download. It would also allow for a better visual hierarchy between title, description, and other information. Each card will show the following informations - Title - Author - number of downloads - description (Note in Koha) The full SQL code from the report will be available by clicking on each card, as well as the full description of the report. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60

[Bug 43669] New: Selenium tests can fail if server is still restarting
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43669 Bug ID: 43669 Summary: Selenium tests can fail if server is still restarting Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- This patch adds a wait_for_server_ready check to t::lib::Selenium, so Selenium-based tests poll the server until it responds successfully before driving it, instead of assuming it is already up. This guards against a race we saw on Jenkins CI: t/db_dependent/selenium/00-onboarding.t and t/db_dependent/selenium/01-installation.t both failed with 'no such element: //div[@class="alert alert-success"]' right after the DB connection check step, immediately after run_tests.pl's get_commands_to_reset_db() restarted Apache/Plack. That helper restarts services and moves straight to running the tests with no readiness wait, so the very first requests can hit workers that are still warming up. The test then fails on a missing page element even though there is no bug in the installer flow itself. A companion issue has been filed against koha-misc4dev to add a readiness wait to run_tests.pl itself: https://gitlab.com/koha-community/koha-misc4dev/-/work_items/108 Test plan: 1. Apply the patch 2. Run t/db_dependent/selenium/01-installation.t (or 00-onboarding.t) against a fresh empty database with KOHA_TESTING=1, as usual 3. Confirm it still passes normally 4. To exercise the new wait: drop/recreate the database, then run "sudo service apache2 restart" and "sudo service koha-common restart", then immediately run the selenium test with no delay. Confirm it either passes (server came up in time) or fails fast with a clear "Cannot wait more for the server to be ready" message rather than a confusing missing-element error deep in the install wizard -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 41091] New: Add ISO18626 to ILL for borrowing
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41091 Bug ID: 41091 Summary: Add ISO18626 to ILL for borrowing 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Bug 37762 is adding lending to Koha using the ISO18628 spec. It would be a good followup if we could also using ISO for borrowing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 43673] New: Memcached problem causes incorrect syspref values
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43673 Bug ID: 43673 Summary: Memcached problem causes incorrect syspref values Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Occasionally, I have this issue where processes (like starman) act strangely - as if a system preference is 0 instead of 1. You look at the database and everything is fine. So you restart memcached and everything magically works again. This suggests to me that perhaps memcached is returning the wrong values, Koha has a bug in Koha::Cache, or Koha isn't handling errors in memcached, or a different Koha is overriding the value for another instance's memcached, or... something I can't even think of yet. I haven't been able to reproduce it: - If I exceed the memcached connection limit, it fails to fetch and it just goes straight to the DB, which is correct. - I've tried exceeding the memory limit but that's tricky to measure, so I don't know if I've exceeded that limit necessarily I'm not sure... but wanted to record something here... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 19642] New: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19642 Bug ID: 19642 Summary: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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 Bug 19225 proposes a warning for users that the config is wrong. I propose instead, we should just ignore that field if automembernum is enabled (since it autocalculates and becomes mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43666] New: Allow plugins to register additional Single Table Inheritance subclasses
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43666 Bug ID: 43666 Summary: Allow plugins to register additional Single Table Inheritance subclasses 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This patch adds Koha::Objects::Mixin::SingleTableInheritance::Pluggable, an extension of the Koha::Objects::Mixin::SingleTableInheritance mixin added in bug 43663. It lets an installed and enabled Koha Plugin register additional Single Table Inheritance (STI) subclasses against a Koha::Objects plural class, provided all of the following are true: 1. The plural class itself opts in at the code level, by composing this mixin instead of the base one. This is a core developer decision, not overridable at runtime. 2. The contributing plugin has been explicitly permitted, for that specific target plural class, via a new per-plugin, per-target toggle in the Plugin management UI. Off by default for every (plugin, target) pair. 3. A new koha-conf.xml entry, enable_plugin_sti_registration, is enabled. Off by default; a full kill-switch overriding both of the above when off, for hosts who want to forbid the capability outright. Discovery reuses Koha's existing Koha::Plugins::GetPlugins({ method => ... }) capability-declaration mechanism (the same approach Koha::SuggestionEngine and Koha::RecordProcessor already use for their own plugin discovery) - no new registry, no filesystem scanning, no Module::Pluggable. A permitted plugin declares its contributions via one public method, additional_sti_classes, returning a hash keyed by target plural class name; each named class self-declares its own dispatch key exactly like a core STI subclass does (see bug 43663), so that key is never duplicated between the plugin and core. A core-registered dispatch key always wins over any plugin contribution. An invalid contribution (fails to load, isn't a subclass of the target's own base class, or doesn't implement the dispatch-key method) is dropped with a logged warning, never a fatal error, so one misbehaving plugin cannot break dispatch for any other row or any other plugin. Koha::File::Transports (already migrated onto the base mixin in bug 43663) is opted into this new capability as the proving-ground consumer, with no other behaviour change - confirmed by the full existing File::Transport test suite passing unmodified with the new capability left at its default (off). This is designed to let a plugin trial a new subclass (for example, an additional file transport backend) without requiring a core patch first; if it proves itself, promoting it into core is a small, two-line change (move the file, add it to the plural class's own reviewed subclass list) with no data migration, since dispatch is driven purely by the persisted column value, not by which mechanism supplied the class. Depends on bug 43663 (Koha::Objects::Mixin::SingleTableInheritance), which this bug builds directly on top of. Test plan: 1. Apply the patches and restart_all. 2. Confirm Administration > File transports behaves identically to before this patch, with everything left at its defaults (no visible change is the expected result at this step). 3. Set enable_plugin_sti_registration to 1 in koha-conf.xml, restart_all. 4. Install and enable a plugin implementing additional_sti_classes for Koha::File::Transports (a companion example plugin will be linked from this bug's comments). 5. In the Plugin management UI's actions menu for that plugin, confirm an option to allow registering classes for Koha::File::Transports appears, and toggle it on. 6. Go to Administration > File transports, create a new file transport using the plugin-contributed transport type, and confirm it dispatches to the plugin's class. 7. Toggle the permission back off. Confirm the plugin-contributed transport type is no longer offered, and any already-created row of that type falls back to generic behaviour rather than erroring. 8. Set enable_plugin_sti_registration back to 0. Confirm re-toggling permission on in the Plugin management UI has no effect while the kill-switch is off. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 42814] New: Advance notice checkboxes enabled in inactive messaging preferences form
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42814 Bug ID: 42814 Summary: Advance notice checkboxes enabled in inactive messaging preferences form Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Bug 28308 added JavaScript to disable the Advance notice transport checkboxes when "Days in advance" is blank. However, the JavaScript only checks the value of the days select. When the messaging preferences form is inactive/read-only and a non-blank days value is selected, the script removes the disabled state from the checkboxes. -- You are receiving this mail because: You are watching all bug changes.

1 12