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

[Bug 36867] ILS-DI AuthorizedIPs should deny explicitly except those listed
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36867 --- Comment #29 from Nick Clemens (kidclamp) <nick(a)bywatersolutions.com> --- Created attachment 181678 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=181678&action=e… Bug 36867: (follow-up) Don't check IP if ILS-DI disabled When ILS-DI is disabled we still expect to return the correct service name/section in the xml, but just indicate that it is disabled. We should skip the check for authorized IPs in this case, as the IP only matters when service is enabled -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39778] New: Documentation needed for Report Type in Saved Reports
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39778 Bug ID: 39778 Summary: Documentation needed for Report Type in Saved Reports Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In Saved Reports there is a column called Type. It's not clear how this column is populated. There are no options to specify type when creating a report from SQL. In step 2 of the a guided report the user can specify a report type such as tabular, summary, or matrix. However those selections are not passed to the saved reports table. At a minimum this is a documentation needed bug, but could be a full fledged bug if there is not a way to populate the column from the UI (that is if it is supposed to be possible). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39776] New: VueJS - Inconsistencies for icons
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39776 Bug ID: 39776 Summary: VueJS - Inconsistencies for icons Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 38010 <i class="fa fa-plus"></i> vs <font-awesome-icon icon="plus" /> We should pick one and stick with it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38010 [Bug 38010] Migrate vendors to Vue -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39563] New: Automatically cancel waiting hold with cancellation request when checked in via SIP
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39563 Bug ID: 39563 Summary: Automatically cancel waiting hold with cancellation request when checked in via SIP 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 22456 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22456#c53 When we added cancellation requests for waiting holds, we made waiting holds with pending cancellation requests automatically cancel if the item is checked in via the staff interface. We should also (optionally?) waiting holds with pending cancellation requests automatically cancel when checked in via SIP. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22456 [Bug 22456] Allow patrons to cancel their waiting holds -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39743] New: Request: items without RFID tags should display as "no RFID"
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39743 Bug ID: 39743 Summary: Request: items without RFID tags should display as "no RFID" Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tara.shepersky(a)tillamookcounty.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Envisionware Stafflink doesn't display an error message when an item lacks an RFID tag. It simply stays blank--which is exactly the way it looks if it's not working. As circulation desk staff, I need a reliable way to know whether the blank display is a software malfunction or reflects a lack of RFID tag, so I can process material efficiently and respect patrons' time. It would be helpful to have a displayed error message in Stafflink, of course. Failing that, it would be helpful for items in Koha to have an RFID yes/no attribute, or display some kind of a "no RFID" message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 36867] ILS-DI AuthorizedIPs should deny explicitly except those listed
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36867 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed --- Comment #28 from Jonathan Druart <jonathan.druart(a)gmail.com> --- t/db_dependent/selenium/ilsdi.t .. # Failed test 'ILS-DI is disabled' # at t/db_dependent/selenium/ilsdi.t line 57. # got: '' # expected: 'ILS-DI is disabled.' # Looks like you failed 1 test of 2. t/db_dependent/selenium/ilsdi.t .. 1/5 # Failed test 'Disabled ILS-DI and enabled OPAC' # at t/db_dependent/selenium/ilsdi.t line 61. # Failed test 'ILS-DI is disabled' # at t/db_dependent/selenium/ilsdi.t line 74. # got: '' # expected: 'ILS-DI is disabled.' # Looks like you failed 1 test of 2. t/db_dependent/selenium/ilsdi.t .. 2/5 # Failed test 'Disabled ILS-DI and disabled OPAC' # at t/db_dependent/selenium/ilsdi.t line 78. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35624] New: Plugin tasks 'type' issue with plugins
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35624 Bug ID: 35624 Summary: Plugin tasks 'type' issue with plugins Change sponsored?: --- Product: Koha Version: master 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When we designed the 'background jobs for plugins', we let the plugins define a `namespace` and each of it's jobs, a `type`. Plugins pick a name and provide a mapping to the implementing class, and then Koha's core handling calculates a plugin-specific type, to avoid collisions, in the form of "plugin_$namespace_$type'. This works correctly for picking the job from the DB, which is what we probably tested. The problem I found is the Koha::BackgroundJob::enqueue method doesn't have enough information to calculate the 'job_type'. For that it would need to: * know we're talking about a plugin job * know which plugin and/or the namespace * know how to calculate the name Right now, it picks the type from $self->job_ype. The simplest workaround for this situation would be (a) to do something like: --- a/Koha/BackgroundJob.pm +++ b/Koha/BackgroundJob.pm @@ -95,12 +95,12 @@ Return the job_id of the newly created job. sub enqueue { my ( $self, $params ) = @_; - my $job_type = $self->job_type; + my $job_type = $params->{job_type} // $self->job_type; and thus allow the plugin to deal with the calculation. The drawback being we give too much responsibility to the plugin author and less flexibility if we find we need to change this. I'm really not sure how bad it would be. Sounds reasonable. Another option would be (b) to require plugin authors to put the fully qualified job type on their plugins [1], and get rid of doing it in Koha::BackgroundJob::plugin_types_to_classes. A third option would be to pass the information about the job coming from a plugin (e.g. enqueue({ is_plugin => 1, plugin_namespage => 'kitchensink' }) and have some internal sub to calculate the final 'type'. Posting this to start the discussion, but I need to finish implementing plugin jobs this week so, hurry! [1] This is what we actually did on the KitchenSink plugin. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 30951] New: Duplicate entry 'ar' for key 'PRIMARY'
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30951 Bug ID: 30951 Summary: Duplicate entry 'ar' for key 'PRIMARY' Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: vbovictor(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In Ubuntu 20.04.4 LTS mysql Ver 15.1 Distrib 10.4.14-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 ERROR koha-upgrade-schema library Upgrade to 21.12.00.013 [19:25:20]: Bug 29605 - Resync DB structure for existing installations ERROR - {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry 'ar' for key 'PRIMARY' at /usr/share/koha/lib/C4/Installer.pm line 739 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 35338] New: Error in SQL syntax when upgrading to 22.06.00.084
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35338 Bug ID: 35338 Summary: Error in SQL syntax when upgrading to 22.06.00.084 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I have done a few upgrades to 22.11.x and 23.05.x now, but I have not seen this error before: Upgrade to 22.06.00.084 [21:21:43]: Bug 31162 - Add primary key to erm_eholdings_packages_agreements ERROR - {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CONSTRAINT erm_eholdings_packages_agreements_uniq, ADD PRIMARY K' at line 3 at /usr/share/koha/lib/C4/Installer.pm line 741 I can find that constraint in two places: * 220600079.pl: unless ( TableExists('erm_eholdings_packages_agreements') ) { $dbh->do(q{ CREATE TABLE `erm_eholdings_packages_agreements` ( `package_id` INT(11) NOT NULL COMMENT 'link to the package', `agreement_id` INT(11) NOT NULL COMMENT 'link to the agreement', UNIQUE KEY `erm_eholdings_packages_agreements_uniq` (`package_id`, `agreement_id`), CONSTRAINT `erm_eholdings_packages_agreements_ibfk_1` FOREIGN KEY (`package_id`) REFERENCES `erm_eholdings_packages` (`package_id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `erm_eholdings_packages_agreements_ibfk_2` FOREIGN KEY (`agreement_id`) REFERENCES `erm_agreements` (`agreement_id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; }); say $out "Added new table 'erm_eholdings_packages_agreements'"; } * 220600084.pl: unless ( primary_key_exists('erm_eholdings_packages_agreements') ){ $dbh->do(q{ ALTER TABLE erm_eholdings_packages_agreements DROP FOREIGN KEY erm_eholdings_packages_agreements_ibfk_1, DROP FOREIGN KEY erm_eholdings_packages_agreements_ibfk_2, DROP CONSTRAINT erm_eholdings_packages_agreements_uniq, ADD PRIMARY KEY(`package_id`, `agreement_id`) }); $dbh->do(q{ ALTER TABLE erm_eholdings_packages_agreements ADD CONSTRAINT `erm_eholdings_packages_agreements_ibfk_1` FOREIGN KEY (`package_id`) REFERENCES `erm_eholdings_packages` (`package_id`) ON DELETE CASCADE ON UPDATE CASCADE, ADD CONSTRAINT `erm_eholdings_packages_agreements_ibfk_2` FOREIGN KEY (`agreement_id`) REFERENCES `erm_agreements` (`agreement_id`) ON DELETE CASCADE ON UPDATE CASCADE }); } Database version: MariaDB 5.7.34-0ubuntu0.18.04.1-log OS: Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 35070] New: Koha plugins implementing "background_jobs" hook can't provide view template
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35070 Bug ID: 35070 Summary: Koha plugins implementing "background_jobs" hook can't provide view template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, Koha plugins implementing the "background_jobs" hook can't provide a template to "View" the job. Instead, you get an error like: Template process failed: file error - background_jobs/plugin_TYPE_ACTION.inc: not found at /kohadevbox/koha/C4/Templates.pm line 127 This should be a pretty easy fix. Basically, Koha::BackgroundJob should have a method that returns "background_jobs/{job type}" and a Koha plugin can override this method to provide its own template. We use the ABSOLUTE option for Template::Toolkit, so you can provide an absolute filepath to a template within the plugin and it'll get processed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37