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

[Bug 15000] Adding patron card images with duplicate descriptions causes data loss
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '17

14 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15000 --- Comment #9 from Marc Véron <veron(a)veron.ch> --- (In reply to MHH Chowdhury from comment #8) > We receive many patrons with same names. If duplication of names overwrites > then it will actually create data loss. We are facing such problem and this > becomes a major issue to rethink about koha. A library patron usually > receives a card number which is unique. If the card numer is same then it > can be overwriten. Can any one suggest us to customize as per our reuirement? The issue described here is about additional images for the patron card (e.g. a logo of your library or a nice background). The patron's image is taken from the patron's details. It is uploaded on the patron's detail page. (You have to set systempreference 'patronimages' to 'allow' to be able to upload patron images). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15000] Adding patron card images with duplicate descriptions causes data loss
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '17

14 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15000 MHH Chowdhury <mhhc(a)iub.edu.bd> changed: What |Removed |Added ---------------------------------------------------------------------------- Deadline| |2017-06-14 CC| |mhhc(a)iub.edu.bd --- Comment #8 from MHH Chowdhury <mhhc(a)iub.edu.bd> --- We receive many patrons with same names. If duplication of names overwrites then it will actually create data loss. We are facing such problem and this becomes a major issue to rethink about koha. A library patron usually receives a card number which is unique. If the card numer is same then it can be overwriten. Can any one suggest us to customize as per our reuirement? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17986] New: Perl dependency evaluation incorrect
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17986 Bug ID: 17986 Summary: Perl dependency evaluation incorrect Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org While I was fixing Bug 17880, I mistakenly created a new bug via a copy/paste error. At the moment, if you run koha_perl_deps.pl -a -c, or go to /cgi-bin/koha/about.pl and click on Perl modules, most installed modules will be coloured yellow indicating they need an upgrade. The fix is a simple one line change, but will help solve a lot of headaches and confusion over people trying to meet dependencies. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 18773] New: t/db_dependent/www/history.t is failing
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18773 Bug ID: 18773 Summary: t/db_dependent/www/history.t is failing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 18411] New: t/db_dependent/www/search_utf8.t fails on 16.11.x
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18411 Bug ID: 18411 Summary: t/db_dependent/www/search_utf8.t fails on 16.11.x Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: katrin.fischer(a)bsz-bw.de QA Contact: gmcharlt(a)gmail.com https://jenkins.koha-community.org/job/Koha_16.11.x_D8/lastCompletedBuild/t… perl t/db_dependent/www/history.t 1..2 ok 1 - Latin characters with umlauts show correctly on the history page. ok 2 - Cyrillic characters with umlauts show correctly on the history page. kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ perl t/db_dependent/www/search_utf8.t 1..66 ok 1 - connect to intranet ok 2 - login to staff client ok 3 - load main page ok 4 - open tools module Link not found at t/db_dependent/www/search_utf8.t line 127. # Looks like your test exited with 255 just after 4. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 14826] Resurrect account offsets table
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '17

13 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14826 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen(a)gmail.com -- 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 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