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

[Bug 24182] New: Cancelling a hold floods the logs
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '21

19 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24182 Bug ID: 24182 Summary: Cancelling a hold floods the logs 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 382 C4::Log::logaction( 'HOLDS', 'CANCEL', $self->reserve_id, Dumper($self->unblessed) ) 383 if C4::Context->preference('HoldsLog'); This ends up loggining a date time object for the cancellation date: 357 $self->cancellationdate( dt_from_string->strftime( '%Y-%m-%d %H:%M:%S' ) ); -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18382] New: action_logs entry for module HOLDS, action SUSPEND is spammy
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '21

19 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18382 Bug ID: 18382 Summary: action_logs entry for module HOLDS, action SUSPEND is spammy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 61842 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=61842&action=ed… Sample Action logs entry for suspend. When a hold is suspended, 'suspend_until' is represented as a DateTime object, complete with locale. All told, this is about 800 lines of text. See the attached 'action_logs.out' To replicate: To test: - Enable the HoldsLog syspref - Add a hold on a record/item - Click on the <Suspend> button Check the logs using module 'Holds' and Action 'Suspend' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 26840] New: Add a 'date added' feature to the facets
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '21

19 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26840 Bug ID: 26840 Summary: Add a 'date added' feature to the facets Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org Our patrons often want to see the newest materials that we've added to the collection. We provide a lot of canned searches to point them to our newest items. But when they do an author or subject search it would be helpful to them to have a 'date added' feature in the facets in the OPAC to allow them to zero in on materials added within the past xxx number of days. For example: Past 30 Days (3) Past 60 Days (3) Past 90 Days (4) Past 180 Days (5) Over 180 Days (221) -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 19621] New: Routing lists tab not present when viewing 'Holds history ' tab for a patron
by bugzilla-daemon＠bugs.koha-community.org 18 Aug '21

18 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19621 Bug ID: 19621 Summary: Routing lists tab not present when viewing 'Holds history' tab for a patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons 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 To recreate: 1 - Enable RoutingSerials syspref 2 - Open a patron record 3 - Click through the tabs on the left side of the screen 4 - Note that 'Routing lists' is visible on all screens except 'Holds history' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 26878] New: Add ability to prevent spending against parent funds
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '21

17 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26878 Bug ID: 26878 Summary: Add ability to prevent spending against parent funds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries construct their funds such that parent funds aren't meant to be spent against directly. Instead, it is expected that the combined child funds will wholly account for the parent. It would be nice to somehow block spending against those parent funds and exclude them from fund selection dropdowns. It'd be more flexible to set this in the fund with some sort of "do not spend against" flag. On the other hand, it'd be simpler as a system preference that just says Do/Don't allow spending against parent funds. Or maybe the options could be "Do allow/ Don't allow / Allow only when child total = parent amount." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 24088] New: Add link to item search in staff client main page
by bugzilla-daemon＠bugs.koha-community.org 17 Aug '21

17 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24088 Bug ID: 24088 Summary: Add link to item search in staff client main page 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In staff client main page, there is a link to advanced search. I propose to add a link to item search below it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 22801] New: Advance search yr uses copydate instead of date-of-publication
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22801 Bug ID: 22801 Summary: Advance search yr uses copydate instead of date-of-publication Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Target Milestone: --- In advanced search with Elasticsearch the limit on years range is actually using copydate : Koha/SearchEngine/Elasticsearch/QueryBuilder.pm in _fix_limit_special_cases() : if ( $l =~ /^yr,st-numeric,ge=/ ) { my ( $start, $end ) = ( $l =~ /^yr,st-numeric,ge=(.*) and yr,st-numeric,le=(.*)$/ ); next unless defined($start) && defined($end); push @new_lim, "copydate:[$start TO $end]"; } With Zebra it uses date-of-publication and also in Koha/SearchEngine/Elasticsearch/QueryBuilder.pm : our %index_field_convert = ( (...) 'yr' => 'date-of-publication', -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 26761] New: Use aria-disabled attribute in OPAC cart for disabled links
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26761 Bug ID: 26761 Summary: Use aria-disabled attribute in OPAC cart for disabled links Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 8712 There is no "disabled" property for the <a> tag, so we have to have a way in addition to color to express that a link is disabled. I think using the "aria-disabled" attribute would be helpful. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8712 [Bug 8712] We should use WAI-ARIA guidelines to help with accessibility -OMNIBUS bug -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 17335] New: waitingreserves.pl cancel button needs simplification
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '21

11 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17335 Bug ID: 17335 Summary: waitingreserves.pl cancel button needs simplification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 I would suggest that the Cancel Hold button is overly complicated and should be simplified. At the very least, this should be an option. Currently (3.22.8) it doesn't seem to matter if there is another hold or if the item is a local item or going somewhere. Its behavior doesn't differ from one button to the next. Aside from that, if this function were to be fixed, say, bug 17010, it really doesn't matter (at least to some libraries) what happens next. The behavior following the press of the button should be self evident. One could also assume that getting information as to what happens next to each hold and customizing the button is using processing time to build the page. Time which is a waste. I think that the buttons next to all the holds should just simply read "Cancel hold". If it is an issue, this should be a preference, that would eliminate any background processes building the buttons, and give a simple Cancel hold label. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 26656] New: Expiration date on waiting holds appears as editable but changes aren't saved
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '21

10 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26656 Bug ID: 26656 Summary: Expiration date on waiting holds appears as editable but changes aren't saved 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When changing the expiration date on a waiting hold from the holds page in staff, the page reloads and the original date remains. As a bug fix we could make it appear as text when the hold is waiting, but there is also bug 25619 asking for the ability to change it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6