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

[Bug 38111] New: Update manager option broken in Change selected suggestions section
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38111 Bug ID: 38111 Summary: Update manager option broken in Change selected suggestions section Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 172502 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172502&action=e… Screenshot of update manager option On the Suggestions management page, beneath the table there is a Change selected suggestions section. Within this section, the Update manager option is broken in 24.05. Users can click on Select manager to conduct a patron search, but the selected patron name is not retained and not applied to the selected suggestions when the Submit button is clicked. Instead, the Managed by column in the table is updated with the name of the logged in user when the Submit button is clicked. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 35017] New: If creating items when ordering, an alert should appear if the item type is not filled out
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35017 Bug ID: 35017 Summary: If creating items when ordering, an alert should appear if the item type is not filled out Change sponsored?: --- Product: Koha Version: unspecified 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 Step to reproduce 1. Create a basket 2. Choose to create items upon ordering 3. Use either a new file or a staged file 4. When adding records to the basket, the required fields seem to only be fund and price. Fill out the required fields. 5. Close the basket 6. Go to receive from that vendor, - add invoice number, then see a 500 error instead of being able to receive anything from that vendor. When a basket is created in Acquisitions with the "create items on ordering", but the item type is not filled in, a 500 error will appear when attempting to receive. Although the item type is not required, thus allowing a user to go through the whole process only to receive a 500 error when receiving. This error will appear regardless of what the user is receiving if an order within that vendor has an order without an item type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 36902] New: Blank year fields should not be indexed.
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36902 Bug ID: 36902 Summary: Blank year fields should not be indexed. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se The comment says 'Only accept years containing digits and "u"' but proceeds to also accept fields with blanks: # Only accept years containing digits and "u" push @{$default_options->{value_callbacks}}, sub { my ($value) = @_; # Replace "u" with "0" for sorting return map { s/[u\s]/0/gr } ( $value =~ /[0-9u\s]{4}/g ); }; If the field contains blanks it is either because it is invalid or because the year is missing, so the field should not be indexed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 36483] New: Calling $object->to_api directly should be avoided
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36483 Bug ID: 36483 Summary: Calling $object->to_api directly should be avoided Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Highlighted on bug 36482, calling $object->to_api directly on our API controllers makes several parameters ineffective. Notably, x-koha-embed. We should call instead: ```perl $c->objects->to_api( $object ) ``` A follow-up bug replacing all existing calls should've been filled but we somehow missed it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 32183] New: Purchase suggestions for logged in patron - doesn't display suggestions made by everyone
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32183 Bug ID: 32183 Summary: Purchase suggestions for logged in patron - doesn't display suggestions made by everyone 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org If OPACViewOthersSuggestions is set to 'Show', for a logged in patron they can only see their own suggestions - not all suggestions as expected. This is working correctly on 22.05.x, but is not working on the current master. To replicate on the current master: 1. Set AnonSuggestions to 'Allow'. 2. Set OPACViewOthersSuggestions to 'Show'. 3. On the OPAC, when not logged in, add a purchase suggestion. 4. On the OPAC, log in as a patron and make a purchase suggestion. 5. Change OPACViewOthersSuggestions to "Don't show". 6. Under Your account > Purchase suggestions, you can only see your own suggestions (as expected). 6. Change OPACViewOthersSuggestions set to "Show". 7. Under Your account > Purchase suggestions, after the "Search for" input field there is a dropdown list with options: 7.1 Select "Suggested by me" and press "Go": the patron's own suggestion(s) are correctly shown. 7.2 Select "Suggested by anyone" and press 'Go': it DOESN'T show all suggestions. Identified when testing bug 20207. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 38151] New: Cumulative restriction does not apply when return in batch
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38151 Bug ID: 38151 Summary: Cumulative restriction does not apply when return in batch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha has the preference CumulativeRestrictionPeriodst that allow to sum restriction for each item overdued This is not working when returning items at once from user's detail page, it only applies first suspension. When returning from circulation module one by one it works fine. test plan: a) Configure circulation rule with 1 days of suspension for earch overdue day b) issue two items to any user c) 2 days after due date return both items at one from moremmebers, it will be suspended 2 days instead 2 + 2 d) issue two items again to any other user c) 2 days after the due date, go to circulation module -- return, d) return one by one... e) the user is restrictd 2 + 2 I have checked from 23.05 and 23.11 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 38178] New: Report pagination is inefficient
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38178 Bug ID: 38178 Summary: Report pagination is inefficient Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It seems that the pagination for report results might be causing more bloat in time rather than helping in processing. I thought the purpose of paginating the results was to improve processing time, but when I run a hefty report (say, against the statistics table), it takes a long time to process 20 results, and then the same amount of time for each page I switch to. If feels like it is gathering the entire set of results, then only carving out the number of results it is supposed to show. I think pagination is only beneficial if the report is only processing the range of results being shown. Otherwise, it should just show all results. For example, a report of 1000 results being paginated in groups of 20 should, in theory, process in about 1/50th the amount of time it would take to process all 1000 results. But it feels like it is taking the time to process all 1000 results. I get the logistics of this. In order to process pages of all the results, sorted, grouped and ordered properly, the whole result needs to be taken into consideration, then broken down. But with each page change, it has to do this all over again. It seems that when the report is run, the results need to be stored in a way that the paging would refer to the stored results, not re-run the report. I don't think there is a way to run the report for each page, just for that page's section of results. It seems that the report needs to run in its entirety initially, but then we should have a more efficient way of going through the pages of results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38152] New: Add "copy to clipboard" feature to barcodes in detail pages
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '24

16 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38152 Bug ID: 38152 Summary: Add "copy to clipboard" feature to barcodes in detail pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 Often we need to copy barcodes for demos or when testing, but coyping the link is hard and not always works well. It would be nice if we offered an option to copy the barcode to the clipboard, maybe using a little icon or similar that could be added later in other places as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 9805] Lost items are un-lost if returned, but not if renewed
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '24

15 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Janet McGowan <janet.mcgowan(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janet.mcgowan(a)ptfs-europe.c | |om -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32256] New: self-checkout batch mode
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '24

15 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32256 Bug ID: 32256 Summary: self-checkout batch mode Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: ddaghita(a)mckinneytexas.org QA Contact: testopia(a)bugs.koha-community.org Please enable batch checkouts on self-checkout machines using koha self-checkout module (/cgi-bin/koha/sco/sco-main.pl?). We have patrons place one book at time on the RFID pad to self-checkout. We would ideally like patrons to stack five or more materials at a time so they checkout more efficiently all at once as it does on the koha staff side. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 105