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

[Bug 22312] New: BlockReturnOfLostItems does not prevent lost items filling holds
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22312 Bug ID: 22312 Summary: BlockReturnOfLostItems does not prevent lost items filling holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- When the preference BlockReturnOfLostItems is set, it prevents checkin from checking the item in, but it does not prevent prompting to fill a hold with that item. Steps to reproduce: 1. Set BlockReturnOfLostItems to Block 2. Place a hold that can be filled by a particular item 3. Mark that item as Lost (or Missing, or any other flavor of lost) 3. Attempt to check in that item Expected results: Message stating that "Item is lost, cannot be checked in./Cannot check in/NOT CHECKED IN", no message about the hold. Actual results: The "Item is lost, cannot be checked in./Cannot check in/NOT CHECKED IN" message displays in the page, but is quickly covered by the popup saying that it can fill a hold. If any of the Confirm buttons (Confirm, Confirm and print slip, Confirm and transfer) is clicked in the hold popup, when the popup closes the message in the page below is removed, leaving no sign that the hold was just filled by an item which is now both being held and also lost. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28896] New: Checkin Slip doesn't work for anonymized checkouts
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28896 Bug ID: 28896 Summary: Checkin Slip doesn't work for anonymized checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The new CHECKINSLIP notice does not work on patrons whose checkouts are anonymized upon checkin. Instead it appears that the patron had no checkins at all! This is due to how the feature gets the old issues. The printslip script takes the borrowernumber and a branchcode and searches the old_issues table which is then filtered by date. I think for this to function for anonymized checkouts we need to pass the actual issue_id's as a list to the slip so they can be looked up directly and not inferred by borrowernumber, branchcode and date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 35234] New: Several HTML validation issues with the import patrons template
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35234 Bug ID: 35234 Summary: Several HTML validation issues with the import patrons template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy 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 Some relevant errors from https://validator.w3.org/nu/: - Bad value for attribute for on element label - Duplicate ID branchcode. - Duplicate ID categorycode. - Element div not allowed as child of element ol in this context. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 19360] New: Give items URL a link text
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19360 Bug ID: 19360 Summary: Give items URL a link text Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Instead of directly displaying the URL entered into the URI (Uniform Resource Identifier) field the patch attached to this bug report will allow the user to input a link text to be displayed instead of the URL on the intranet and OPAC detail page. -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 39830] New: Add order claim object definition
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39830 Bug ID: 39830 Summary: Add order claim object definition Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 39031] New: ILL plugins should provide themselves the template path
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39031 Bug ID: 39031 Summary: ILL plugins should provide themselves the template path 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Right now, Koha assumes (in `Koha::ILL::Request->expand_template`) that `$plugin->new_ill_backend` returns a Koha::Plugin object that implements the required methods for acting like a proper ILL backend. This is implied by the internal use of `bundle_path`: ```perl my $backend_plugin = $self->get_backend_plugin( $self->_backend->name ); if ($backend_plugin) { # New way of loading backends: Through plugins $backend_dir = $backend_plugin->bundle_path; $backend_tmpl = $backend_dir; ``` I'm writing a backend plugin that has a convenient `templates/` dir to better organize the many pieces. My `new_ill_backend()` method returns a new object that is designed to eventually inherit from `Koha::ILL::Backend` when time comes. The current implementation assumes that everything is contained in the plugin's bundle path in a very specific way. I propose we either allow the backend to tell where to look for templates: ```diff - $backend_dir = $backend_plugin->bundle_path; + $backend_dir = $self->_backend->template_path; ``` or implement a plugin method for the job: ```diff - $backend_dir = $backend_plugin->bundle_path; + $backend_dir = $backend_plugin->ill_template_path; ``` i.e. just implement a plugin method, that will return the path for querying the backend templates I'd go with the first option, leaving it to the author's creativity to organize things the way they want. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 34556] New: Add a template 'Accessibility statement' page to the default data
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '26

28 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34556 Bug ID: 34556 Summary: Add a template 'Accessibility statement' page to the default data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) 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 Blocks: 23003 We should add a template 'accessibility statement' using the pages feature of Koha and add it optionally to the installer default data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23003 [Bug 23003] Accessibility improvements -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 33218] New: Should the 'Main contact method' field override the AutoEmailPrimaryAddress at patron-level?
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33218 Bug ID: 33218 Summary: Should the 'Main contact method' field override the AutoEmailPrimaryAddress at patron-level? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org While I was working on bug 33191 et al. I asked myself if the 'Main contact method' drop down was somehow linked to AutoEmailPrimaryAddress, as a way to override the system preference at patron level. I was told no, but I think it would make sense... If for example AutoEmailPrimaryAddress is set to 'home' (primary email), and a patron chooses their work email as their main contact method, there is no way to send email notices to their work email, is there? I would see it as something like the CheckPrevCheckouts, where it is possible to override the syspref at the patron-level. Not sure how it would work with custom values as introduced in bug 31498, however... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 22832] New: Require plugins to specify the methods they implement
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

1 18

[Bug 25316] New: Koha::Plugin::Base should automatically find plugin metadata and store it in the database for retreival
by bugzilla-daemon＠bugs.koha-community.org 27 Jan '26

27 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25316 Bug ID: 25316 Summary: Koha::Plugin::Base should automatically find plugin metadata and store it in the database for retreival Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We should store plugin metadata in the database for easy retrieval. Koha::Plugins::Base::get_metadata should check the database for its own metadata. If it doesn't find anything in the database, it should check itself for a $metadata global as it does now, but if one does not exist, it should then check for a companion PLUGIN.yml file ( from Bug 24631 ) in the bundle_path() and load the metadata from there. In either case it should then be stored in the database. InstallPlugins() should force the plugins metadata to be updated from source to the database, as the plugin metadata may ( and should ) have changed in the updated plugin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4