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

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

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64265|0 |1 is obsolete| | -- You are receiving this mail because: 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 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 --- Comment #26 from Nick Clemens <nick(a)bywatersolutions.com> --- There was a fair bit of discussion here that underlying code needs a rewrite - between the two options here I think I would vote for the Alternate, simply because it fixes the problem without locking us into the Capitalization, less new code on top of code the needs rewritten. Obsoleting the original patch in favor of the new, I appreciate everyone's work here and would love to see this one move ahead quickly. -- You are receiving this mail because: 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 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 --- Comment #25 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 64266 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64266&action=ed… Bug 15438 [Alternate Solution] - Checking out an on-hold item sends holder's borrowernumber in AF (screen message) field. Description: Let's say that 'Holding Patron' puts a hold on title 'ASDF'. If 'SIP Patron' then tries to check out ASDF, Holding Patron's card number appears in the AF (i.e. Screen Message) field. This only occurs if the hold has *not* yet been finalized -- If ASDF is waiting for Holding Patron, the screen message will read "Item is on hold shelf for another patron." The screen message containing only the Holding Patron's borrowernumber is confusing because a) It contains no context as to the nature of the number showing on the screen b) SIP devices work with borrower card numbers, so the number being returned has the wrong context. Furthermore, we're leaking patron information in a place where we probably would never check. Replicating the problem: Set up instance with two patrons, as well as a bib/item to put on hold/check out. Make sure that circ rules allow holds. Set up SIPconfig.xml to allow checkouts on the IP/port of your choice. Start SIP2. Make sure that authentication, checkin and check out work for the 'SIP Patron'. Ensure that AllowItemsOnHoldCheckout is set to "Don't Allow". In the steps to replicate, the Title/barcode of the item on hold/being checked out will be 'asdf'. The Holding Patron will be referred to as 'holder' and the checkout patron will be referred to as 'sipper'. Let's say that sipper's borrowernumber is 52. 1/ Place a biblio level hold for asdf, with holder as the holding patron. 2/ Start `sudo tail -f /var/log/syslog | grep sip` 3/ Attempt to check out asdf to sipper. You will see the sip checkout message '11...' followed by a '120...|AF52|...' sip checkout response. This indicates that the checkout has failed (which we would expect), and that the screen message is '52'. Example using ./misc/sip_cli_emulator.pl $ ./misc/sip_cli_emulator.pl -a 127.0.0.1 -p 6001 -su staff -sp staff -l CPL --patron 23529001223636 --password 1234 --item 1234 -m checkout Attempting socket connection to 127.0.0.1:6001...connected! SEND: 9300CNstaff|COstaff|CPCPL| READ: 941 Trying 'checkout' SEND: 11YN20151229 05321120151229 053211AOCPL|AA23529001223636|AB1234|ACstaff|AD1234|BON|BIN| READ: 120NUN20151229 053211AOCPL|AA23529001223636|AB1234|AJTheories of human development :|AH|AF52|BLY|BV5.00|BHUSD|BT06| -- You are receiving this mail because: 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 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64264|0 |1 is obsolete| | --- Comment #24 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 64265 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64265&action=ed… Bug 15438 - Checking out an on-hold item sends holder's borrowernumber in AF (screen message) field. The returns from C4::Circulation::CanBookBeIssued used to be structured as a hashref of entries like REASON => { data => 'foo', moredata => 'bar', }; Some entries still are. But many are now REASON => 1, data => 'foo', moredata => 'bar', The sip Checkout routine still assumed the former, as it reports any causes it was not aware of (to maintain support for a changing api) The data fields could leak into the screen message field of the response. e.g. the borrowernumber or surname of the borrower who has a hold on an issued title. Some real messages were getting obscured by this This patch sanatizes the return from from CanBookBeIssued by removing keys which are not all uppercase It also fixes a case where the key's data element was used for the screen message when we should use the key itself Updated the documentation of CanBookBeIssued to flag up the assumption re case and the fact that 3 elements rather than two may be returned The loop through the returned keys was a bit bogus so we now explicitly jump out if noerror is unset -- You are receiving this mail because: 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 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #61738|0 |1 is obsolete| | --- Comment #23 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 64264 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64264&action=ed… Bug 15438: Stop leaking data into SIP screen message The returns from C4::Circulation::CanBookBeIssued used to be structured as a hashref of entries like REASON => { data => 'foo', moredata => 'bar', }; Some entries still are. But many are now REASON => 1, data => 'foo', moredata => 'bar', The sip Checkout routine still assumed the former, as it reports any causes it was not aware of (to maintain support for a changing api) The data fields could leak into the screen message field of the response. e.g. the borrowernumber or surname of the borrower who has a hold on an issued title. Some real messages were getting obscured by this This patch sanatizes the return from from CanBookBeIssued by removing keys which are not all uppercase It also fixes a case where the key's data element was used for the screen message when we should use the key itself Updated the documentation of CanBookBeIssued to flag up the assumption re case and the fact that 3 elements rather than two may be returned The loop through the returned keys was a bit bogus so we now explicitly jump out if noerror is unset -- You are receiving this mail because: 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 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11443] Refactoring code sending basket from OPAC/intra
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11443 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 18740] New: [16.05.12-16.05.13] Cannot modify patron password
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18740 Bug ID: 18740 Summary: [16.05.12-16.05.13] Cannot modify patron password Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 13664] Add password strength plugin
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13664 --- Comment #75 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Olli-Antti Kivilahti from comment #74) Most of the code from this bug report will be replaced with patches from bug 18298. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13664] Add password strength plugin
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13664 Olli-Antti Kivilahti <olli-antti.kivilahti(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olli-antti.kivilahti(a)jns.fi --- Comment #74 from Olli-Antti Kivilahti <olli-antti.kivilahti(a)jns.fi> --- There already is an implementation for this feature. Bug 12617 I recommend you avoid adding new sysprefs and use borrower category parameters instead. There are way too many sysprefs already. Think on how to remove excess, not add new ones. See Bug 12617. The way the patches are split to separate pieces is pretty cool. This would be a great tutorial on how to write code for Koha! I believe the RM can squash these together when pushing to master. Personally I cannot find enough integrity to keep the code commits in such small and condensed chunks. Should be small enough steps for the community small-steps-guideline. -- You are receiving this mail because: You are watching all bug changes.

1 0