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

[Bug 14576] Allow arbitrary automatic update of location on checkin
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14576 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #61940|0 |1 is obsolete| | Attachment #61941|0 |1 is obsolete| | Attachment #61942|0 |1 is obsolete| | Attachment #61944|0 |1 is obsolete| | Attachment #61945|0 |1 is obsolete| | Attachment #61946|0 |1 is obsolete| | Attachment #61947|0 |1 is obsolete| | Attachment #61948|0 |1 is obsolete| | Attachment #61949|0 |1 is obsolete| | Attachment #61950|0 |1 is obsolete| | --- Comment #64 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 64656 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64656&action=ed… Bug 14576 - Allow arbitrary automatic update of location on checkin This patch adds a new syspref "UpdateItemLocationOnCheckin" which accepts pairs of shelving locations. On check-in the items location is compared ot the location on the left and, if it matches, is updated to the location on the left. This preference replaces ReturnToShelvingCart and InProcessingToShelvingCart preferences. The update statement should insert values that replciate these functions. Note existing functionality of all items in PROC location being returned to permanent_location is preserved by default. Also, any items issued from CART location will be returned to their permanent location on issue (if it differs) Special values for this pref are: _ALL_ - used on left side only to affect all items _BLANK_ - used on either side to match on/set to blank (actual blanks will work, but this is an easier to read option) _PERM_ - used on right side only to return items to permanent location Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Set the new system preference UpdateitemLocationOnCheckin to the following (assuming sample data): NEW: FIC FIC: GEN 4) Create an item, set its location to NEW 5) Check in the item, note its location is now FIC 6) Check in the item again, note its location is now GEN 7) Check in the item again, note its location remains GEN 8) Test using _ALL_, _BLANK_ and _PERM_ for updates 9) Try entering various incorrect syntax in the pref and note you are warned Sponsored by: Arcadia Public Library (http://library.ci.arcadia.ca.us/) Middletown Township Public Library (http://www.mtpl.org/) Signed-off-by: Cathi Wiggins <cwiggins(a)ArcadiaCA.gov> Signed-off-by: Megan Wianecki <mwianecki(a)mtpl.org> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14576] Allow arbitrary automatic update of location on checkin
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14576 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4148] Advanced Search not sorting by author
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4148 --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to Fiona Borthwick from comment #5) > One of our new customers has reported this also. It is not just the case for > the Advanced Search - quick search is the same. Both OPAC and staff. It's certainly confusing for the patrons that an author A-Z search returns seemingly nonsensically sorted results first, but this bug isn't as simple as "fix sorting." Koha is sorting correctly, because "nothing comes before something." When sorting on 100a, results which have no 100a will be sorted first. Is it even possible for Zebra to create an index on "100a if present, 700a if not, but use the first 700a as sorted by first and second indicators?" -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 13178] cardnumber field length is too short
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

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

1 0

[Bug 13178] cardnumber field length is too short
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13178 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64645|0 |1 is obsolete| | --- Comment #14 from Marc Véron <veron(a)veron.ch> --- Created attachment 64647 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64647&action=ed… Bug 13178: Correct Max cardnumberlength ($max is the value of the max size of a card number) - $max not hardcoded anymore in C4::Memeber - $max now correctly adapts to the field of cardnumber in database Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13178] cardnumber field length is too short
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13178 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64644|0 |1 is obsolete| | --- Comment #13 from Marc Véron <veron(a)veron.ch> --- Created attachment 64646 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64646&action=ed… Bug 13178: increase max value of CardnumberLength testplan 1 - Apply patch 2 - Run updatedatabase.pl 3 - Update dbix scheme 4 - set the value of CardnumberLength to a value between 16 and 32 5 - Check you can enter a propper cardnumber (modify to 32 instead 20) + max value now depends on the database field value to Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13178] cardnumber field length is too short
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13178 --- Comment #12 from Marc Véron <veron(a)veron.ch> --- Tested both patches together, will sign off. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4148] Advanced Search not sorting by author
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4148 Fiona Borthwick <fiona.borthwick(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fiona.borthwick@ptfs-europe | |.com --- Comment #5 from Fiona Borthwick <fiona.borthwick(a)ptfs-europe.com> --- One of our new customers has reported this also. It is not just the case for the Advanced Search - quick search is the same. Both OPAC and staff. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 13178] cardnumber field length is too short
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13178 Baptiste <baptiste.wojtkowski(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #11 from Baptiste <baptiste.wojtkowski(a)biblibre.com> --- @Marc Veron Sorry I didn't write to update the DBix schema, if you do this this should correct your problem However you discovered another bug: max size should be set to 16 in your case, because you had a wrong max value Please apply second patch and try again ;) To test the second patch: -> set your syspref to (100,200) before applying patch => max shouldn't change -> do the same after applying patch => max should change -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13178] cardnumber field length is too short
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '17

26 Jun '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13178 --- Comment #10 from Baptiste <baptiste.wojtkowski(a)biblibre.com> --- Created attachment 64645 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64645&action=ed… Bug 13178: Correct Max cardnumberlength ($max is the value of the max size of a card number) - $max not hardcoded anymore in C4::Memeber - $max now correctly adapts to the field of cardnumber in database -- You are receiving this mail because: You are watching all bug changes.

1 0