November 2020 - Koha-bugs - lists.koha-community.org

[Bug 20533] New: Call Number Search plugin functionality
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '21

17 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20533 Bug ID: 20533 Summary: Call Number Search plugin functionality Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The call number search plugin has great functionality- it would be great to get a little bit more features with this. There is no scrolling feature or the ability to look at the next page of results, so it would be nice to de-dup on the call number. Then the same call number is not repeated over and over again and then more unique call numbers can be displayed. In addition, if more than one title has the same call number, it is not helpful to see that multiple times in this search also. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 20532] New: Display of 245 fields in basket.pl
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '21

17 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20532 Bug ID: 20532 Summary: Display of 245 fields in basket.pl Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, when adding an item to a basket and viewing the basket.pl, only certain fields are visible (245a is the only field from the title) on this page. It would be beneficial to see the entire 245 field including all the subfields to the 245 fields on this page. This would help to know more specifically what format is being ordered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 24132] New: search_with_library_limits vs filter_by_branch_limitations
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '21

17 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24132 Bug ID: 24132 Summary: search_with_library_limits vs filter_by_branch_limitations Change sponsored?: --- Product: Koha Version: unspecified 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 Depends on: 20443 Aside from the naming of these two subroutines (implemented at different times), Koha::Patron::Attribute::Types->search_with_library_limits and Koha::Patron::Attributes->filter_by_branch_limitations looks similar and that the code must be simplified. The join table is between borrower_attribute_types and branches (borrower_attribute_types_branches). So Koha::Patron::Attribute::Types can inherit directly from Koha::Objects::Limit::Library, not Koha::Patron::Attributes There are a couple of ways to deal with that: 1. Improve Koha::Objects::Limit::Library => Sounds wrong as there is no join table between borrower_attributes and branches 2. Remove Koha::Patron::Attributes->filter_by_branch_limitations and replace it by something like: my $attribute_types = Koha::Patron::Attribute::Types ->search_with_library_limits; my $attribute = $patron->extended_attributes ->search({ code => { -in => attribute_types->column('code') } }); Which sounds more correct. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20443 [Bug 20443] Move C4::Members::Attributes to Koha namespace -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25183] New: cleanup-database.pl --del-exp-selfreg fully deletes borrowers - should go into deleted-borrowers
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '21

16 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25183 Bug ID: 25183 Summary: cleanup-database.pl --del-exp-selfreg fully deletes borrowers - should go into deleted-borrowers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The cleanup database job for deleting expired self registrations fully deletes borrowers instead of transferring them to deleted borrowers. This is a problem when libraries think they are deleting email unverified patrons instead of ones that haven't moved out of the category, an easy thing to be confused about. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 25067] New: Move PO file manipulation code into gulp tasks
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25067 Bug ID: 25067 Summary: Move PO file manipulation code into gulp tasks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 101

[Bug 18195] New: Charge for expired holds per patron category
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18195 Bug ID: 18195 Summary: Charge for expired holds per patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ExpireReservesMaxPickUpDelayCharge allows one charge to be applied to all holds that expire. However, each patron category can have a unique hold fee. It would be preferable if each patron category could also have a unique 'hold expired' fee, so different patron categories could be charged different amounts (or not at all) for expired holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 26523] New: In reserve/request.pl biblioitemnumber is used where biblionumber is required.
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26523 Bug ID: 26523 Summary: In reserve/request.pl biblioitemnumber is used where biblionumber is required. Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the fix of bug 24185, (commit 18ad5f5eea8aab8414783f4b75408cfebd2518da) bibliotemnumber is used where biblionumber is required. The consequence is that ItemsAnyAvailableAndNotRestricted is called on the wrong record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 26429] New: If a waiting hold has expired (date has passed)- looking at the request.pl page, the expiration date is for tomorrow
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '21

13 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26429 Bug ID: 26429 Summary: If a waiting hold has expired (date has passed)- looking at the request.pl page, the expiration date is for tomorrow 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Have a waiting hold - the expiration date of 9/9/2020. 2. Reserve table shows 9/9, request.pl shows 9/9 3. Fast forward to 9/10 4. If library is not expiring holds, this hold expiration date will now show the expiration date of 9/11 on the request.pl page. 5. The reserve table still shows the 9/9 date. It would appear that since the date picker (from the reserves.pl page) can not show dates in the past or even for the current date, it will show the next available date. This is confusing! This bug seems very relevant to the bug I am filing: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21147 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 25789] New: New expiration date editor on request.pl can set a date in the past
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '21

09 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25789 Bug ID: 25789 Summary: New expiration date editor on request.pl can set a date in the past Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When creating a new request on request.pl, staff cannot set a hold expires on date in the past -- input name="expiration_date". When editing an existing request, however, the new datepicker for editing the expiration date on request.pl does allow for a date to be set in the past -- input name="expirationdate". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 27008] New: Broken SQL statement formed in Breeding.pm
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '21

09 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27008 Bug ID: 27008 Summary: Broken SQL statement formed in Breeding.pm 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org The C4/Breeding.pm code doesn't properly form SQL statements and gives error instead: > DBD::mysql::st execute failed: You have an error in your SQL syntax; check the > manual that corresponds to your MariaDB server version for the right syntax to > use near '' at line 5 [for Statement "SELECT import_record_id, file_name, isbn, > title, author > FROM import_biblios > JOIN import_records USING (import_record_id) > JOIN import_batches USING (import_batch_id) > WHERE "] at /usr/share/koha/lib/C4/Breeding.pm line 100. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7