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

[Bug 33617] New: Items in cart location still need to show permanent location on search.pl
by bugzilla-daemon＠bugs.koha-community.org 01 May '25

01 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33617 Bug ID: 33617 Summary: Items in cart location still need to show permanent location on search.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org The search.pl page shows results for items, but only shows the cart location, if used, for the item location. Librarians want a quick way to locate items, and removing the permanent location forces librarians to click into records to see the permanent location. Cart locations should show next to the permanent location, either emphasized or in parenthesis. But wherever a shelf location is shown, permanent location should always show, and the cart location should be added to it in some discernable way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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 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 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

[Bug 28171] New: Serial enumeration / chronology sorting is broken in biblio page
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '25

28 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28171 Bug ID: 28171 Summary: Serial enumeration / chronology sorting is broken in biblio page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nugged(a)gmail.com, oleonard(a)myacpl.org Depends on: 27980 In catalogue/detail.pl page the "Serial enumeration / chronology" column sorting is broken after the changes in bug 27980. To reproduce problem add 2 items, one with "A" and one with "B" value in "h - Serial Enumeration / chronology item" field. Then go to catalogue/detail.pl and try to sort by clicking on the "Serial enumeration / chronology" column. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27980 [Bug 27980] Replace obsolete title-string sorting: Catalog templates -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48