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

[Bug 17620] New: Fix format of date/data-times in Swagger definition
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17620 Bug ID: 17620 Summary: Fix format of date/data-times in Swagger definition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: hector.hecaxmmx(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, lari.taskula(a)jns.fi, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 16276, 17607 Bug #17607 highlighted the lack of a defined format for date and date-time fields in our api responses. We should settle on a response form and validate it to ensure it's consistently given across the codebase. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16276 [Bug 16276] When automatically deleting expired borrowers, make sure they didn't log in recently https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17607 [Bug 17607] Fix patron definition in Swagger -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 28184] New: Terminology: Edit or Modify on forms for changing information in Koha
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28184 Bug ID: 28184 Summary: Terminology: Edit or Modify on forms for changing information in Koha Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the OPAC staff interface we use a mix of 'Edit' and 'Modify' on forms for changing information in Koha. Should we be using Edit or Modify for editing forms? Do we have a preferred term or does it not matter? Should we be more consistent? Some examples: - Cataloging for a record: Edit > Edit record, Edit items, Edit items in batch; form is labelled 'Editing [title]', 'Edit Item #XXX', 'Edit items' - Administration > Z39.50/SRU servers administration: Edit for action menu, on the form 'Modify Z39.50 server' - Administration > Libraries: Edit for the action menu, on the form we use 'Modify library' - Tools > Patron lists: Edit for action menu, on the form 'Modify patron list' - Tools > News: Edit for action menu, 'Edit news item' for the form - Patrons: Edit for the action, 'Modify patron [name...]' - Acquisitions > Vendor edit: 'Edit vendor' button, 'Update: [vendor name]' - Acquisitions > Baskets: 'Edit basket' button, 'Edit basket [basket name]' - Tools > CSV profiles: Edit for the action menu, 'Modify a CSV profile' Whatever way is decided (if anything) we should al least be consistent in the future, both from a user interface point of view and to help with translation. (Raised following comment 8 for bug 28037) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28150] New: Don't include Koha::Object-base modules
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28150 Bug ID: 28150 Summary: Don't include Koha::Object-base modules 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We should use Koha::Objects-based modules, not the Koha::Object -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 28435] New: CanBookBeRenewed returns only a single status and falsely indicates renewal can be overridden
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28435 Bug ID: 28435 Summary: CanBookBeRenewed returns only a single status and falsely indicates renewal can be overridden Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Similar to bug 22866 - depending on system settings you may or may not be able to override a hold to renew an item. For instance - if an item is on hold, and the renewal limit has been reached CanBookBeRenewed returns 'TooMany' Checking the 'Override renewal restrictions' button makes the hold appear renewable. Executing the renewal fails because of 'On hold' Returning all status would allow us to sort which can be overridden and which cannot, however, there would be a performance cost for patrons with many checkouts. We could also develop an API route to check when the override button is checked, calculating if renewal is possible with override and only allowing the checkbox if so. Alternately, we could add a system preference to always return all statuses and allow the library to choose performance vs completeness of response. I am not sure the bets path and am filing this bug for discussion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 25758] New: Items scheduled for automatic renewal do not show that they will not renew due to a hold
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25758 Bug ID: 25758 Summary: Items scheduled for automatic renewal do not show that they will not renew due to a hold Change sponsored?: --- Product: Koha Version: master 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 In the issues table on circulation.pl, we're no longer showing a message of "On Hold" when an item is scheduled for automatic renewal, is outside of the No Renewal Before window, but has a hold that will block renewal. This is a regression, most likely caused by bug 19014. To recreate: 1- set NoRenewalBeforePrecision to date only 2- set a circ rule to auto-renewal=yes, no renewal before=0, checkout period to 7 days 3- check item out 4- confirm item shows Scheduled For Automatic Renewal in issues table 5- place a hold on the item for another patron 6- reload issues table for patron 1, confirm checkout still shows "scheduled for automatic renewal" rather than "on hold" 7- change No Renewal Before value to 7 8- reload issues table for patron 1, confirm checkout now shows "on hold" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 81

[Bug 27892] New: api/v1/acquisitions_vendors.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27892 Bug ID: 27892 Summary: api/v1/acquisitions_vendors.t is failing randomly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org 10:51:09 koha_1 | # Failed test 'No tests run for subtest "list() and delete() tests | authorized user"' 10:51:09 koha_1 | # at t/db_dependent/api/v1/acquisitions_vendors.t line 112. 10:51:09 koha_1 | DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Cannot delete or update a parent row: a foreign key constraint fails (`koha_kohadev`.`vendor_edi_accounts`, CONSTRAINT `vfk_vendor_id` FOREIGN KEY (`vendor_id`) REFERENCES `aqbooksellers` (`id`)) [for Statement "DELETE FROM `aqbooksellers`"] at /kohadevbox/koha/Koha/Objects.pm line 208 10:51:09 koha_1 | # Looks like your test exited with 255 just after 1. Master_D9 (#1590) Looks like we are missing a "on delete cascade" on vendor_edi_accounts -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 28874] New: We need javascript equivalents to many of our TT plugins
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28874 Bug ID: 28874 Summary: We need javascript equivalents to many of our TT plugins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have some really great TT plugins and includes.. but with a slow but steady move to using ajax for various things, many of these TT specific snippets would benefit from a javascript equivalent. Some examples off the top of my head: * AuthorisedValues * Biblio title * Accountline type -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 28917] New: Catalog tab on table settins is missing tables in "Jumpt to:" list
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28917 Bug ID: 28917 Summary: Catalog tab on table settins is missing tables in "Jumpt to:" list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you go to administration > table settings and look at the "Catalog" tab, you will notice that there is only one table listed in "Jump to", but there are multiple in the list. Also: Tab is labelled catalog, but list is headed with "Catalogue tables" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 28515] New: Make it easy to run batch modification on "all"
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28515 Bug ID: 28515 Summary: Make it easy to run batch modification on "all" Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Batch modification of items and records (and maybe more things as well?) relies on supplying IDs in a file or a list, or coming in from a report. But sometimes you really do want to modify everytghing. Could we make that easier by supplying a "select all" option? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 28851] New: Separate AllFinesNeedOverride syspref into intranet and selfcheck versions
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28851 Bug ID: 28851 Summary: Separate AllFinesNeedOverride syspref into intranet and selfcheck versions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 The syspref AllFinesNeedOverride makes all checkouts require a staff override. It's enforced on both the intranet and on selfchecks. It ends up completely blocking checkout on selfchecks for patrons with any fines, as there is no mechanism for a staff override. It would be clearer and more flexible to split this into two sysprefs, one that applies to the intranet and one that applies to selfchecks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2