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

[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 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 37912] New: Catalog concerns - Broken link under concern title
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '25

28 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37912 Bug ID: 37912 Summary: Catalog concerns - Broken link under concern title Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In the catalog concerns page, nothing happens when you click on the title of a concern. To recreate: 1. Enable the CatalogConcerns system preference 2. In a bibliographic record, click New > New catalog concern 3. Fill out the title (and optionally the description) 4. Click Submit 5. Go to Cataloging > Catalog concerns 6. Click on the title of the concern --> Nothing happens According to the manual, it used to lead to the concern details modal. -- You are receiving this mail because: You are watching all bug changes.

1 27

[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