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

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal --- Comment #22 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- De-escalating this one.. it's been around for 6 years and hasn't really recieved the attention a critical should.. I personally feel at the time it was critical and it's still a nice to fix.. but as we're moving toward elastic search and possible deprecating QueryParser entirely I'm not sure how to progress this bug. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 --- Comment #21 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- (In reply to Jonathan Druart from comment #17) > (In reply to Martin Renvoize from comment #16) > > I've attempted a rebase of the patch.. it's not an area I'm all that > > familiar with so testing is required. > > Reading previous comments it seems that this patch will introduce > regressions. I think there are regressions for specific versions of zebra.. but I also felt that relevance issues outweighted the regressions introduced. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11420] Patron preference to restrict staff from changing location
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11420 Sally <sally.healey(a)cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14180] Make "Always show checkouts immediately" a global setting
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14180 Kelly McElligott <kelly(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |--- CC| |kelly(a)bywatersolutions.com Status|RESOLVED |REOPENED --- Comment #12 from Kelly McElligott <kelly(a)bywatersolutions.com> --- I want to open this back up, please. I believe that this is worth talking about again. A system preference would be optimal to allow libraries to turn on/off. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 24558] New: Catching old holds on check in
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24558 Bug ID: 24558 Summary: Catching old holds on check in 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 Many libraries have public hold shelves, where holds that are waiting are on a publicly accessible shelf where patrons can pick them up and check them out. Sometimes these libraries have patrons that 'mistakenly' pick up the hold and 'forget' to check them out. These items are then returned and the library checks them in, not know the previous status. The same hold is triggered, and the hold goes back out on the shelf. While we print the expiration date of the hold on the slip, not all staff notice the date. I would propose that if an expired hold, or a hold with an expiration shorter than that assigned to ReservesMaxPickUpDelay is checked in, a message or alert displays, to alert staff that this is an old hold. They would still have all the usual options with that hold, but would be alerted to its old status. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 15261] Verify if checkouts or reserves requests periods overlap with existing reserves
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 --- Comment #80 from Julian Maurice <julian.maurice(a)biblibre.com> --- Patch rebased on master -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15261] Verify if checkouts or reserves requests periods overlap with existing reserves
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #94871|0 |1 is obsolete| | --- Comment #79 from Julian Maurice <julian.maurice(a)biblibre.com> --- Created attachment 98383 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98383&action=ed… Bug 15261: Check if checkout/reserve request overlaps existing reserves When checking out or placing hold, we should check if an existing reserve whose period overlap exists. - A user places a hold from opac whose requested period overlaps with an existing reserve period => prevent reserve - A librarian places a hold from staff whose requested period overlaps with an existing reserve period => Warn librarian (Ask for confirmation) - A librarian makes a checkout from staff whose requested period overlaps with an existing reserve period => Warn librarian (Ask for confirmation) Test plan: Enable syspref: AllowHoldDateInFuture OPACAllowHoldDateInFuture PreventChechoutOnSameReservePeriod and PreventReservesOnSamePeriod 1 (staff side): - Place a hold on title (which has only one items) level with start date and expiration date. - Place another hold (also title level) with period overlaping this reserve. - Check you are warned about an existing reserve 2 (staff side): - Place a hold on title (which has more than one items) level with start date and expiration date. - Place another hold (also title level) with period overlaping this reserve. - Check you are NOT warned about an existing reserve. Because it remains at least one item not reserved. 3 (staff side): - Place a hold on item level with start date and expiration date. - Place another hold on item level with period overlaping this reserve. - Check you are warned about an existing reserve. 4 (opac side): - Do the same than for staff side. Instead of a warn, reserve is prevented. 5: - Place a hold on title (which has only one items) level with start date and expiration date. - Try to checkout the unique item from this title with period overlaping the reserve period. - Check you are warned about an existing reserve 6: - Place a hold on title (which has more than one items) level with start date and expiration date. - Checkout an item from this title with period overlaping the reserve period. - Check you are NOT warned about an existing reserve. 7: - Place a hold on item level with start date and expiration date. - Checkout this item period overlaping the reserve period. - Check you are warned about an existing reserve 8: - Create a checkout (i.e from ${TODAY} to ${TODAY + 10 days}), - Place a hold on the same item from ${TODAY + 11 days} to ${TODAY + 30 days}), - Check that you cannot renew the checkout. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24571] New: Attempting to place multi hold requests on Firefox only places some of them
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24571 Bug ID: 24571 Summary: Attempting to place multi hold requests on Firefox only places some of them Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: agustinmoyano(a)theke.io Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the staff client do a search that returns 20+ results that can be held Select all Place hold Confirm The api submits ~8 requests, then the page moves to the hold results, but not alll records are held -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 23620] New: Improve checkin message when suspensions are accrued at check into include number of 'days' overdue and the resulting no. of suspension days.
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23620 Bug ID: 23620 Summary: Improve checkin message when suspensions are accrued at check into include number of 'days' overdue and the resulting no. of suspension days. Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: niamh.walker-headon(a)it-tallaght.ie QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In a library using suspensions only, not fines and not restrictions, when an overdue item is returned there is no visibility for staff on the length of time is it overdue and staff sometimes end up manually calculating the days to answer queries as to why a suspension / fine is a particular length. Staff want to be able to say that book was 2 days / 20 days overdue and your account is suspended for X days until X date. Please improve messaging on circulation so that when an overdue item is returned, the number of days overdue is communicated to staff in addition to any suspension / restriction / fine. Failing this, on checkin of overdue items, it would be very useful to be able to click on a link to view suspensions and see detail about which item is overdue (barcode?) and how many days that item is overdue so that the staff member can explain to a patron why the suspension is X amount of days. This change will save staff time dealing with queries (more efficient use of time), make the process more transparent which in turn provides a better customer service. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11281] Printing holds awaiting pickup prints both tabs
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11281 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #95737|0 |1 is obsolete| | --- Comment #3 from David Nind <david(a)davidnind.com> --- Created attachment 98371 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98371&action=ed… Bug 11281: Printing holds awaiting pickup prints both tabs This patch adds columns configuration to the holds awaiting pickup tables. Doing so helps solve the printing issue by adding a "Print" option to both tables. Using this print function will provide a printable version of only that table. To test you should have multiple holds in your system which are marked "waiting" and some which have been waiting longer than the value specified in the ReservesMaxPickUpDelay system preference. Apply the patch and go to Circulation -> Holds awaiting pickup. - On both the "Holds waiting" and "Holds waiting over..." tabs the DataTable should display correctly and all the controls should work, including the columns settings and the choices in the export menu. - Confirm that the "Print" action creates a printable version of only the table you are viewing. - Go to Administration -> Columns settings -> Circulation. - Change some visibility controls for the tables under the "holds_awaiting_pickup" heading (id=holdso and id=holdst). Confirm that these changes are reflected in the "Holds waiting" interface. Signed-off-by: David Nind <david(a)davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

1 0