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

[Bug 31207] New: The OPAC Shelf browser fails to display local cover images
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '25

30 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31207 Bug ID: 31207 Summary: The OPAC Shelf browser fails to display local cover images Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org In the OPAC Details page for a biblio, opening the Shelf browser will display adjacent items next to each other based on their call number and also display any cover images found. It's a very useful OPAC feature that allows librarians to have a "virtual" look at their library shelves. This is currently broken *when local covers are exclusively in use*, as it fails to fetch the related local cover images from the DB. Steps to reproduce: TL;DR: Just visit the sandbox URL below and see for yourself ;-) https://opac-shlfbrwsr.sandboxes.biblibre.eu/cgi-bin/koha/opac-detail.pl?bi… Go to Home > Administration > System preferences in the Staff interface: - in section 'OPAC -> Shelf browser', make sure OPACShelfBrowser is enabled (i.e. set to 'Show') - in section 'Enhanced content -> Local or remote cover images', make sure both LocalCoverImages and OPACLocalCoverImages are enabled (i.e. set to 'Display') - make sure no other cover image provider is enabled - make sure OpacSeparateHoldings and OpacSeparateHoldingsBranch are set to 'Don't separate' and 'home library', respectively Next, in the Staff interface, find a record without any local cover images (either at the biblio or at the item level), having at least one item attached to it that has a Call number (the call number value can be anything -- it's only needed to trigger the display of the 'Browse shelf' hyperlink). Use the 'Images' tab in the Details page of the record to upload a local cover image at the biblio level (do *not* upload any item-level cover image). Finally, in the OPAC, visit the Details page of the record you just added the cover image to, and click on the 'Browse shelf' link found in the 'Call number' column. When the Shelf browser expands, you'll notice that there is no cover image displayed for the item(s) that belong to your test biblio. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 37485] New: Hold rules not respected for item groups if other items on bib are holdable
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '25

30 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37485 Bug ID: 37485 Summary: Hold rules not respected for item groups if other items on bib are holdable Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Circulation rules that limit holds aren't working properly when items with 0 allowed holds are added to item groups if there are holdable items on the bib, even if all items in a group have 0 holds allowed. To replicate: 1. Set circ rules to 0 holds allowed for test patron category/item type (ex: reference) 2. Create item with item type reference 3. Try to place hold, and note message saying holds aren't allowed (in this scenario, it can be placed by override) - works as expected. At this step, I'm also unable to place a hold via the OPAC. 4. Create an item group (REF), and add your reference item to it 5. Add another item to the bib that *is* holdable 6. Select your patron to place a hold. Note that there is no error message (which makes sense, since once item is holdable). 7. Select the 'Hold next available item from an item group' radio button, and then select your REF group. Note that there is no indication that the only item in this group is not holdable. 8. Click 'Place hold'. The hold places successfully, and there is no warning or popup that this hold isn't allowed. I can also successfully place a hold on the REF item group from the OPAC. The behavior appears to be the same in 23.05.10, 23.11, and 24.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 29730] New: Register text should be consistent in OPAC
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29730 Bug ID: 29730 Summary: Register text should be consistent in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In OPAC when you are not logged in you can see a text telling to register : > git grep -i 'register here' -- koha-tmpl/ koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc: <p>Don't have an account? <a href="/cgi-bin/koha/opac-memberentry.pl">Register here.</a></p> koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-auth.tt: <a href="/cgi-bin/koha/opac-memberentry.pl">You may register here.</a> koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-main.tt: <p>Don't have an account? <a href="/cgi-bin/koha/opac-memberentry.pl">Register here.</a></p> koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-registration-confirmation.tt: [% IF PatronSelfRegistration && PatronSelfRegistrationDefaultCategory %]<div id="patronregistration"><p>Don't have an account? <a href="/cgi-bin/koha/opac-memberentry.pl">Register here.</a></p></div>[% END %] We see that opac-auth.tt text is not consistant with other ones. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 31544] New: Guarantees and Guarantors
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31544 Bug ID: 31544 Summary: Guarantees and Guarantors Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Guarantees and Guarantors are buried in the details page. Handy, but not the place I think to look. Wondering if the Add guarantee button at the top of the patron account could be: * Changed to Guarantee * Visible on both Adult and Children accounts * Change to a dropdown with option to add Guarantee/Guarantor * Also list links to guarantees/guarantors -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[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

[Bug 36549] New: es_indexer_daemon.pl leaks memory
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '25

29 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36549 Bug ID: 36549 Summary: es_indexer_daemon.pl leaks memory 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org background_jobs_worker.pl runs its tasks in child processes which return their memory to the OS when they complete. es_indexer_daemon.pl runs everything in itself which means if it needs to allocate a large amount of memory for an indexing job, it will hold on to that memory allocation for its entire process life. -- I've got an es_indexer_daemon.pl which is using over 1GB of memory. Once it's done with its indexing activity, I'm going to restart it to get it back down to a more reasonable amount of allocated memory. I reckon we should be forking off child processes to do the worker. We don't need many. We just need 1 that is short lived so that it can return the memory back to the OS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 36006] New: Patron notification methods
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '25

28 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36006 Bug ID: 36006 Summary: Patron notification methods Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Patrons have the option to turn on or off any notifications for any of the methods available (email, print, sms, phone). Could we offer another method that allows them to be notified when they login to their account? So, basically, when selected for a particular notice, the notice appears in their opac messages. When they mark it as read, there could be an indicator in the staff side next to that notice when they marked it read. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3