August 2016 - Koha-bugs - lists.koha-community.org

[Bug 9699] Allow patrons to see notices sent to them in their OPAC account
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '16

23 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9699 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Summary|allow patrons to see notice |Allow patrons to see |log |notices sent to them in | |their OPAC account -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '16

23 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Severity|major |critical -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '16

23 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon(a)cdalibrary.org --- Comment #3 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- I have just confirmed this issue. I have tested the SIP response and can see the AF field cycling through different responses each time we scan the item. This is pretty messed up. Our self check has been showing the name of the patron the item is on hold for in some instances. Would love to see this fixed ASAP. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14535] Late orders doensn't show orders with price = 0
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14535 --- Comment #5 from Sandre Cunha <cunha(a)monterey.org> --- I don't think it would be a problem if the 0-priced items showed up on the late list. I don't have a suggestion as I don t quite understand the intended purpose of including 129 AND aqorders.rrp <> 0 130 AND aqorders.ecost <> 0 in the selection, and what the ramifications of removing one or both would be. We do not "track" gifts in the manner you described, as ours are either gifts of physical items or monetary donations (from which items are ordered in the usual way, but from a trust fund account.) A larger problem is that we do so much ordering of pre-publication items, and there is no way to adjust the "lateness" according to the scheduled publication date. For example, right now we have a purchase suggestion for an item that will not be published until April 2017. We want to make the order to get the item (by a popular author) into the OPAC so patrons can see it is on order and place holds, but if I do that now, the item would be "late" in 30 days, even though it will not be published for 6 months. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14535] Late orders doensn't show orders with price = 0
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14535 --- Comment #4 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Sandre, what is your suggestion to resolve this? Would it be a problem if those showed up as late orders after the normal period? How are you treating gifts? I think one of the libraries explained that they use 0 for tracking gifts that they expect to receive or have asked for or when they don't know how much an item will cost. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14390] Fine not updated from 'FU' to 'F' on renewal
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 --- Comment #49 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Kyle M Hall from comment #48) > (In reply to Katrin Fischer from comment #45) > > > How to solve this? Can we remove the issue id in accountlines after > > > switching to F? Or should UpdateFine no longer update a F record although it > > > has the right issue id, but add a new record? > > > > I think it should add a new line as it's a 'new fine'. If we differentiate > > between F and FU cleanly, we can keep the issue_id too, I think? > > Katrin has is exactly. If the same checkout goes overdue twice, the patron > should have two separate fines ( and each one will show a different due date > for the same checkout ). > > This new followup will stop UpdateFine from updating closed out fines. We are coming closer to a solution! But please note that we need type F (imo) in the totalamount calculation and the max fine reduction. We should focus on what happens next in UpdateFine. The test $data->{'amount'} != $amount is not sufficient. Here we should exclude type F somehow. But take care with $type that you get from CalcFine. It may not be what you expect it to be .. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8073] Sound cue when checking in items on hold
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8073 --- Comment #3 from Cab Vinton <bibliwho(a)gmail.com> --- OK, thank you, Katrin! For anyone else tracking this, ByWater has a helpful tutorial on how to use the AudioAlerts functionality here: http://bywatersolutions.com/2016/04/19/koha-3-22-custom-sound-alerts/ -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16593] Access Control - Malicious user can delete the search history of another user
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

1 0

[Bug 14390] Fine not updated from 'FU' to 'F' on renewal
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 Josef Moravec <josef.moravec(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josef.moravec(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14797] Cancelling orders with no alert to existing holds
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '16

22 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14797 --- Comment #4 from Sandre Cunha <cunha(a)monterey.org> --- (In reply to Ray Delahunty from comment #3) > This remains a problem in 3.20 (we move to 16.05 soon). As a workaround we > have set up a report to be run whenever an order is cancelled, to look for > reservations. We have added this to the homepage, and our cataloging / > acquisitions staff can easily access it. > > SELECT o.ordernumber, b.title, b.author, p.surname, p.firstname, > r.reservedate, > r.cancellationdate, r.branchcode > FROM reserves r > LEFT JOIN borrowers p USING (borrowernumber) > LEFT JOIN biblio b USING (biblionumber) > LEFT JOIN aqorders o USING (biblionumber) > LEFT JOIN aqbasket n using (basketno) > WHERE o.ordernumber=<<Order number>> > > Better than nothing I suppose. > > Ray Delahunty > University of the Arts London And then how are the patrons notified? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0