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

[Bug 24019] New: Patron batch modification based on borrowernumber
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '21

03 Sep '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24019 Bug ID: 24019 Summary: Patron batch modification based on borrowernumber Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org It would be useful for librarians to be able to batch modify patrons based on a list of borrowernumbers instead of just lists of cardnumbers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 23792] New: Send borrowernumbers from report to batch modify
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '21

27 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23792 Bug ID: 23792 Summary: Send borrowernumbers from report to batch modify Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Apologies if this bug is a dupe, I really thought I'd seen this one before and now can't find it. It'd be great to be able to run a report listing patrons and send them straight to batch patron modification, as we can now do with items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 19294] New: ILS-DI: HoldTitle and HoldItem don't consider " on shelf holds allowed" setting
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '21

27 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19294 Bug ID: 19294 Summary: ILS-DI: HoldTitle and HoldItem don't consider "on shelf holds allowed" setting 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: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Steps to reproduce: 1. In "Circulation and fines rules", set "On shelf holds allowed" to "If all unavailable" for all branches/patron categories/itemtypes 2. Try to place a hold using ILS-DI on a title that have all its items available (e.g. http://opac.master.koha-dev/cgi-bin/koha/ilsdi.pl?service=HoldTitle&patron_…) 3. The hold is placed but it shouldn't be allowed. 4. Cancel the hold 5. Try to place a hold using ILS-DI on an available item (e.g. http://opac.master.koha-dev/cgi-bin/koha/ilsdi.pl?service=HoldItem&patron_i…) 6. The hold is placed but it shouldn't be allowed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22696] New: Simplify visibility opac-ISBD.pl
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '21

26 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22696 Bug ID: 22696 Summary: Simplify visibility opac-ISBD.pl 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Take advantage of bug 22694 to simplify the logic in it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 22150] New: Make it easier to unselect one member permission after selecting all
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '21

19 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22150 Bug ID: 22150 Summary: Make it easier to unselect one member permission after selecting all 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Go to a patron account page Click more -> Set permissions At the moment, if you select Superlibrarian, it is the same as selecting all. However, you can't then unselect one permission because the checkboxes are disabled. It is very slow and tedious to have to select every other checkbox one by one. There should be a way to disable the checkboxes when I want to unselect one or some permissions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[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 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 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 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