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

[Bug 27297] New: When itemtype is marked as required in OpacSuggestion MandatoryFields the field is not required
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27297 Bug ID: 27297 Summary: When itemtype is marked as required in OpacSuggestion MandatoryFields the field is not required 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Two issues: 1 - We only add the required class, we don't make the input required 2 - We don't add a 'blank' option, so the field is preselected -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 27957] New: Attributes removed in LDAP
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27957 Bug ID: 27957 Summary: Attributes removed in LDAP Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Working on bug 27857 (actually, on the follow-up bug 27956), I found that the Koha::Patron->extended_attributes setter is used to write the new attributes. This happens inside a Koha::Patron::Attribute::Types loop which is used to determine 'valid' attributes (good). The problem is 'extended_attributes' actually calls: $self->extended_attributes->filter_by_branch_limitations->delete; which deletes the existing attribute. So calling it for setting a single attribute makes it... delete all the attributes each time! There's also some funky logic in checkpw_ldap. The $patron object seems to be retrieved in several places and even inside a loop. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 27909] New: When upgrading, old sysprefs are only copied in english news items
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '23

05 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27909 Bug ID: 27909 Summary: When upgrading, old sysprefs are only copied in english news items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I don't know how to reproduce this... When we upgraded from 18.05 to 19.05, the contents for OpacNavRight was copied into the new news item OpacNavRight (english), but not fr-CA which is also installed in all our clients' OPACs. Now we've started upgrading from 19.05 to 20.05 and the old system preferences are still only copied into the english news items. It's a bit more problematic because there are a lot more and all our clients at least have something in opacheader. My colleague Philippe coded a script to copy everything into our fr_CA news items, but this should probably be handled in the upgrade (atomic update?). Here are the news items from old system preferences: - OpacNavRight (19.05?) - opacheader (20.05 bug 22880) - OpacCustomSearch (20.05.03 bug 23796) - OpacMainUserBlock (20.05 bug 23794) - opaccredits (20.05.03 bug 23795) - OpacLoginInstructions (20.05.03 bug 23797) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 26917] New: Searching for patrons: member.pl vs circulation.pl
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26917 Bug ID: 26917 Summary: Searching for patrons: member.pl vs circulation.pl Change sponsored?: --- Product: Koha Version: master 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 When searching for a partial name, you get a list of results. Depending on whether you start your search in check out or patron search, the results differ. The records are the same, but the layout and information shown is different. This is confusing to staff, as they don't remember which place to search for the information they want to search through. I would suggest that we standardize the results so they are consistent. On top of that, I would like to see the ability to pick what information is included the table of results. There are fields we don't need to see, and there are fields we would like to see, in order to determine which patron is the right one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 26980] New: UNIMARC_sync_date_created_with_marc_biblio.pl is setting MarcFieldForModifierName to CLI
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26980 Bug ID: 26980 Summary: UNIMARC_sync_date_created_with_marc_biblio.pl is setting MarcFieldForModifierName to CLI Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Hi, Since Bug 22600 patches there's a context userenv and MarcFieldForModifierName is modified, but like Bug 21487 it doesn't really make sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 26981] New: Writing off Accruing Fines causes another accruing fine to appear at checkin
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26981 Bug ID: 26981 Summary: Writing off Accruing Fines causes another accruing fine to appear at checkin Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is happening on Koha 20.05.05, similar to [24146] bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24146 if a library writes off an accruing fine and then checks that item in, that fine will be re-charged to the patron as Fine Returned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 27895] New: Internal server error when trying to change picup location for a hold with no valid locations
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27895 Bug ID: 27895 Summary: Internal server error when trying to change picup location for a hold with no valid locations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 If 'AllowHoldPolicyOverride' is set to 'Allow' staff can place a hold that has no allowed pickup locations. If staff try to alter the pickup location from the patron's record there is an internal server error To test: 1 - Set 'Default checkout, hold and return policy' on Admin->Circ rules to Hold policy: From home library Hold pickup library match: Item's home library 2 - Set AllowHoldPolicyOverride to Allow 3 - Place an item level hold for a patron on an item from another branch - there should be a warn while placing, but hold is allowed 4 - Bring up the patron details or checkout page 5 - Click the holds tab 6 - Try to change the hold pickup location 7 - You get an error: There was an error:error Internal Server Error 8 - In logs: The method Koha::Libraries->branchcode is not covered by tests! Trace begun at /kohadevbox/koha/Koha/Objects.pm line 592 Koha::Objects::AUTOLOAD('Koha::Libraries=HASH(0x5631e45dc298)') called at /kohadevbox/koha/Koha/Hold.pm line 252 Koha::Hold::__ANON__ at /kohadevbox/koha/Koha/Hold.pm line 252 Koha::Hold::is_pickup_location_valid('Koha::Hold=HASH(0x5631e448ae48)', 'HASH(0x5631e45cf638)') called at t/db_dependent/Koha/Hold.t line 203 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

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