April 2017 - Koha-bugs - lists.koha-community.org

[Bug 14598] itemtype is not set on statistics by C4::Circulation:: AddReturn
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14598 Gwendal JONCOUR <gwendal.joncour(a)univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gwendal.joncour@univ-rennes | |2.fr --- Comment #135 from Gwendal JONCOUR <gwendal.joncour(a)univ-rennes2.fr> --- Here in Université Rennes 2, France, we tried on a dump of our production, with statistics from 2012 to now. For the numbers, we have approximately 2.4M lines in statistics table (300K distinct itemnumbers from return stats with no itemtype set), 900K lines in items, 46K in deleteditems, 500K lines in biblioitems and 70K in deletedbiblioitems. Despite days running the updatedatabase.pl script, the first query of the 16.06.00.039 update keep stuck in "sending data" state. We tried to upgrade our test server to equivalent to our production server (12 cores and 48GB of RAM) with no more result. We tried also to reduce our statistics to keep only those from 2015 to now but the query keep stuck. Is there anybody who succeed to apply the 16.06.00.039 update script to a production equivalent database ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14803] Rental and fine fees are not updating on circulation screen
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14803 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14803] Rental and fine fees are not updating on circulation screen
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14803 --- Comment #23 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 62294 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62294&action=ed… Screenshot showing a problem with the checkout box (In reply to Srdjan Jankovic from comment #20) > Things have moved on meanwhile, and it seems to me that the page is being > force reloaded now, so I'm not sure how useful this patch is. I don't find that this page is being reloaded when renewing from the checkboxes. This looks like it's working correctly to update the fee numbers, but something weird happens when the patron's fines are past the noissuescharge limit. The checkout form is hidden from all users, whether they have permission to override or not. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14642] Add logging of hold modifications
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14642 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=18445 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7550] Self checkout: limit display of patron image to logged-in patron
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7550 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7550] Self checkout: limit display of patron image to logged-in patron
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7550 --- Comment #7 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- No you cannot, unless you know the cardnumber. Everybody can guess the 'ck' value from the cardnumber. It may be better to use a hash based on the image. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7550] Self checkout: limit display of patron image to logged-in patron
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7550 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62272|0 |1 is obsolete| | --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 62289 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62289&action=ed… [SIGNED-OFF] Bug 7550 - Self checkout: limit display of patron image to logged-in patron The patron image display in the self-checkout takes a GET parameter from the image source, so if someone copied the image location and substituted the barcode string they could browse through all patron images: <img alt="" src="/cgi-bin/koha/sco/sco-patron-image.pl?borrowernumber=XXXX"> To reproduce: - Enable self checkout, go to [Your Server]//cgi-bin/koha/sco/sco-main.pl - Log in with a user 'A' who has a patron image - Copy the address of the patron image into an other browser window - Change the borrowernumber to on of an other user 'B' having a patron image - Verify that the patron image is displayed To test: - Apply patch, restart plack / memcached - Try to reproduce - Verify that you can no longer display the image of user 'B' by tweaking the image address Signed-off-by: Owen Leonard <oleonard(a)myacpl.org> https://bugs.koha-community.org/show_bug.cgi?id=7750 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7550] Self checkout: limit display of patron image to logged-in patron
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7550 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10382] collection not returning to null when removed from course reserves
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 --- Comment #26 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, so is the problem that we save 'unchanged' instead of the original value, no matter if it was changed or not? And 'null' would be confusing, as it could mean 'unchanged' as well as 'was empty before'? So could it work like that? - change from a to b (changed, store a) - change from none to a (changed, store none) < current problem - change from a to none (changed, store a) - change from none to none (unchanged, store unchanged) - change from a to a (unchanged, store unchanged) I think the advantage of <unchanged> is currently that if you change the collection/location while the item is in the course reserve, with 'unchanged' it won't reset it by accident when you remove the item from the course reserve - the new value will stay. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10382] collection not returning to null when removed from course reserves
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '17

18 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10382 --- Comment #25 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- (In reply to Jonathan Druart from comment #24) > This <UNCHANGED> stuff smells like a very bad codding pattern. > Could not we use empty string and undef/NULL to handle empty values? Hello Jonathan, I don't really see how to do that. If you create a course item this way: my $ci_id2 = ModCourseItem( itemnumber => $itemnumber, itype => '', ccode => 'BOOK', holdingbranch => '<UNCHANGED>', location => '<UNCHANGED>', ); or this way my $ci_id2 = ModCourseItem( itemnumber => $itemnumber, ccode => 'BOOK', holdingbranch => '<UNCHANGED>', location => '<UNCHANGED>', ); This results to the same when getting the course with GetCourseItem: itype is undef. Empty or null value are retrieved the same and we are unable to know if the value has changed or not. -- You are receiving this mail because: You are watching all bug changes.

1 0