May 2023 - Koha-bugs - lists.koha-community.org

[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 33787] New: Remove option to archive system debit types
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33787 Bug ID: 33787 Summary: Remove option to archive system debit types Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It should not be possible to archive system debit types (such as ACCOUNT, OVERDUE, RENT, etc). Only the manual types should have that option. To recreate: 1. Go to Administration > Debit types 2. Click Show all debit types --> Note that *all* debit types have both the Edit and Archive buttons Possibly a regression from bug 32450 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 33197] New: Terminology: rename GDPR_Policy system preference
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '23

04 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33197 Bug ID: 33197 Summary: Terminology: rename GDPR_Policy system preference Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com GDPR is a European Union (and, at time of writing, UK) law. The GDPR_Policy system preference is about a patron giving consent to their personal data being processed in line with the library's privacy policy. The name of the preference is vague: there could be many policies implemented by libraries to comply with GDPR. It also makes the preference look irrelevant for libraries outside the areas where GDPR applies, while it may be useful for libraries anywhere. The preference could be renamed something like "PrivacyPolicyConsent". The description text in the staff interface would need to be updated, as well as the description of the PrivacyPolicyURL preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[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