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

[Bug 30152] New: Elasticsearch - queries with OR don't work with limits
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30152 Bug ID: 30152 Summary: Elasticsearch - queries with OR don't work with limits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: kevin.carnes(a)ub.lu.se When a query with "OR" is combined with a limit in Elasticsearch, the precedence is not preserved and the results are not correct. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 31085] New: The return claims table no longer reloads on resolution
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31085 Bug ID: 31085 Summary: The return claims table no longer reloads on resolution 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 29519 Blocks: 28854 In bug 29519 we split out the returns claim resolution modal and form so they could be re-used on the check-in screen. However, I missed something. When resolving a claim from the details or checkout screens the claims table should be refreshed. Currently, we are calling an undefined function and this leads to noise in the console and the table not refreshing as it should. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28854 [Bug 28854] Add ability to create bundles of items https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29519 [Bug 29519] Add option to resolve a return claim at checkin -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 31087] New: Undefined notes in returns claims get stringified to 'null'
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31087 Bug ID: 31087 Summary: Undefined notes in returns claims get stringified to 'null' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Blocks: 28854 The returns claims tables available on checkout and details pages display the null values stringified for notes. This was found whilst testing bug 28854 and fixed inline there, but we felt it should be split out as it's own minor bug. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28854 [Bug 28854] Add ability to create bundles of items -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 30865] New: Koha::Biblio->get_components_query should double quote Host-item search
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30865 Bug ID: 30865 Summary: Koha::Biblio->get_components_query should double quote Host-item search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As noted at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175#c522 and https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29418#c11, an unquoted Host-item query returned by Koha::Biblio->get_components_query can cause syntax errors in Zebra. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 31164] New: When staging records, 'ignore items' resets to 'import all items'
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31164 Bug ID: 31164 Summary: When staging records, 'ignore items' resets to 'import all items' Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When staging a record for import and you chose 'ignore items' from the last pull down, it will still parse for items. And once you get to 'manage staged records' the option will have reset to 'add all items'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30416] New: Patron search results page UX fixes
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30416 Bug ID: 30416 Summary: Patron search results page UX fixes 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 30063 introduces some visual side effects which would be nice to fix.. the 'select all' bar floats in a weird location is the main issue.. perhaps we could add this into a more general component of the datatables wrapper? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 29652] New: Move Koha::Biblio->get_marc_* to Koha::Biblio::Metadata
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '22

17 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29652 Bug ID: 29652 Summary: Move Koha::Biblio->get_marc_* to Koha::Biblio::Metadata 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When you look at the methods code, you notice - It is tied to the Koha::Biblio::Metadata->record - The code branches depending on information that is passed, that is already present at the Koha::Biblio::Metadata object/level (MARCFLAVOUR=schema, the record itself) There should still exist a Koha::Biblio->authors/notes method to retrieve this information at that level, but calling the metadata object methods. This way the caller could do: my $biblio = Koha::Biblios->find( $biblio_id, { prefetch => ['biblio_metadata'] } ); and even save some queries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 27805] New: Use input type "email" for email preferences
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '22

16 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27805 Bug ID: 27805 Summary: Use input type "email" for email preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We already have "class: email" in the pref files, we should check for that value when generating the markup. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 29189] New: Expired serial subscriptions still automatically generate issues
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '22

16 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29189 Bug ID: 29189 Summary: Expired serial subscriptions still automatically generate issues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials 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 know this is like a Pandora's box, But I just can't get my head around why expired subscriptions would still generate issues even after the expiry date. To replicate : Create a subscription that would end in the past 1. Search for a record in the staff interface 2. Click on the title to go to the record details page 3. Click on New > New subscription 4. Click Next 5. Fill in the second part of the new subscription form - First issue publication date : enter a date in the past, e.g. 2020-01-01 - Frequency : choose a frequency, e.g. 1/3month - Subscription length : enter a number of issues for the subscription, e.g. 4 - Subscription start date : enter a date on or before your first issue publication date, e.g. 2020-01-01 - Numbering pattern : choose a numbering pattern, e.g. Number - Begins with : enter a number, e.g. 42 6. Click on Test prediction pattern 7. Click Save subscription Receive one issue for this subscription 8. Click Receive 9. Change the status to Arrived 10. Change the Expected on date to something close(r) to the Published on date, e.g. 2020-01-01 11. Click Save Make one issue late 12. Click Generate next Receive the rest of the issues normally 13. Repeat steps 8-11 for all remaining issues -- Once you have received all issues in the subscription, it should say "Subscription expired" in the Serial collection page. -- Note that the next issue was automatically generated even though it's not supposed to be in the subscription Like Katrin said in the chat, I don't think receiving should be completely forbidden in expired subscriptions as there can be late issues that you might receive in the future. And the act of "receiving" is actually editing the issues, so if I need to mark one as "Missing" in the future, I need to be able to do that even when the subscription is expired. But, I don't think additional issues should be generated after the prescribed number of issues/weeks/months in the subscription or after the subscription end date. My problem is rally with the automatic creation of issues. Although I must say, I don't work in a library, so maybe what I'm saying doesn't make sense in a day-to-day serial workflow. But I did receive a question from a client asking why issues were still being generated even after the subscription is expired and I can't find a logical explanation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28797] New: Hold reminder email should use All Libraries notice
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '22

16 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28797 Bug ID: 28797 Summary: Hold reminder email should use All Libraries notice 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 15986 Bug 15986 introduces a hold reminder email. It only knows how to use branch-specific notices and will fail if your only HOLD_REMINDER notice is for All Libraries. To confirm: - have a patron with a valid email address and Hold notices set to go out via email in their messaging prefs - place a hold for your patron, get it to Waiting status - confirm that you have the default HOLD_REMINDER email notice for All Libraries but no library-specific HOLD_REMINDER notice - perl misc/cronjobs/holds/holds_reminder.pl -c -v to run the holds reminder cron - get "Message 'HOLD_REMINDER' content not found for [your branch]" - create the notice for your branch - re-run the cron - patron gets notice Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15986 [Bug 15986] Add a script for sending hold waiting reminder notices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4