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

[Bug 15446] Koha::Object[s]->type should be renamed to _type to avoid conflict with column name
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15446 --- Comment #20 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 48006 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48006&action=ed… Bug 15446: Rename Koha::Object[s]->type with _type In a few case (at least systempreferences and export_format (csv profiles), the type method of Koha::Object and Koha::Objects can be in conflict with the column names. Indeed systempreferences.type exists and so the method will return 'Systempreference' (the name of the module) instead of the value of the row in DB. I have found at least 1 place where it can cause issue: In C4::Context->set_preference: 601 my $syspref = Koha::Config::SysPrefs->find( $var ); 602 my $type = $syspref ? $syspref->type() : undef; 603 604 $value = 0 if ( $type && $type eq 'YesNo' && $value eq '' ); type will always be 'Systempreference' and the YesNo pref will be set to an empty string '' instead of 0. I am not sure about the consequences of this, but it is preferable to fix it ASAP. To reproduce: 0/ Do not apply this patch 1/ Edit a YesNo prefs, AutoEmailOpacUser for instance 2/ Set it to "Don't sent" 3/ Check the value in DB, it should be set to an empty string, instead of 0 4/ Apply this patch and try again. Now the value should be 0 Followed test plan, value is now 0 as expected. Signed-off-by: Marc Véron <veron(a)veron.ch> 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 15446] Koha::Object[s]->type should be renamed to _type to avoid conflict with column name
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15446 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46424|0 |1 is obsolete| | Attachment #46425|0 |1 is obsolete| | Attachment #46426|0 |1 is obsolete| | Attachment #46427|0 |1 is obsolete| | --- Comment #19 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 48005 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48005&action=ed… Bug 15446: Add tests Signed-off-by: Marc Véron <veron(a)veron.ch> 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 15632] Move the messages related code to Koha::Patron::Messages
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15632 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #47580|0 |1 is obsolete| | Attachment #47581|0 |1 is obsolete| | Attachment #47582|0 |1 is obsolete| | Attachment #47583|0 |1 is obsolete| | Attachment #47584|0 |1 is obsolete| | Attachment #47585|0 |1 is obsolete| | Attachment #47586|0 |1 is obsolete| | Attachment #47587|0 |1 is obsolete| | --- Comment #28 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 48004 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48004&action=ed… Bug 15632: Koha::Patron::Messages - Add new classes The following 4 CRUD subroutines in C4::Members: - AddMessage - DeleteMessage - GetMessagesCount - GetMessages could be replaced with a new package based on Koha::Objets. This patchset will add the 2 Koha::Patron::Message[s] classes, then use it to replace the different calls to these subroutine. It will slightly reduce the size of C4::Members Signed-off-by: Marc Véron <veron(a)veron.ch> 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 15632] Move the messages related code to Koha::Patron::Messages
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

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

1 0

[Bug 15632] Move the messages related code to Koha::Patron::Messages
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15632 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |15446 CC| |kyle(a)bywatersolutions.com Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15446 [Bug 15446] Koha::Object[s]->type should be renamed to _type to avoid conflict with column name -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15446] Koha::Object[s]->type should be renamed to _type to avoid conflict with column name
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15446 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |15632 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15632 [Bug 15632] Move the messages related code to Koha::Patron::Messages -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15546] Software Error for all access to Label Creator
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15546 MJ Ray (software.coop) <mjr(a)software.coop> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjr(a)software.coop Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from MJ Ray (software.coop) <mjr(a)software.coop> --- The co-op fixed this. To summarise: The log file included "Table 'koha_library.creator_layouts' doesn't exist" It seems that labels_upgrade.pl did not run successfully during an upgrade back in the mists of time and updatedatabase.pl does not check its exit status. As a consequence, patroncards_upgrade.pl did not run successfully either. The database structure has been fixed by reading those and kohastructure.sql and now the label creator does not produce this error. I will mark this as FIXED and leave it up to others to decide whether it's a bug that updatedatabase.pl doesn't check the exit status of extra upgrade scripts. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14695] Add ability to place multiple item holds on a given record per patron
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 Benjamin Daeuber <bdaeuber(a)cityoffargo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdaeuber(a)cityoffargo.com --- Comment #69 from Benjamin Daeuber <bdaeuber(a)cityoffargo.com> --- We ran this through the sandbox and adjusted the test plan as follows: a. We should probably update the test plan to make sure we’re all in the same place: 1. Patron class needs at least the same number of holds allowed as you are going to allow per record 2. Item level holds need to be enabled on the item type b. Another note -- and this would vary by library – we adjusted the default for holds on available items from “waiting” to “on hold” so they were not active until they were checked in That said, here’s what we noted: 1. If you start in the staff interface a patron can place holds on more than 3 items on a bib record, regardless of circ rules. But the behavior is kind of strange. If holds are placed from the staff interface, it lets us place 4 holds. When a patron places holds from the OPAC it stops at 3, and then prevents staff from placing additional holds in the staff interface. 2. Selecting an option from the drop down while “next available” is checked places multiple holds on the selected item. 3. Related, the dropdown could cause policy enforcement issues for some libraries. Say we allow users to put 10 items per record on hold (a realistic number if you consider periodicals records that may have hundreds of items) and a user selects it. If there is only 1 item, a patron could place it on hold 10 times and keep checking it out, bypassing renewal restrictions. Some comments on the user experience 1. When you look at the holds queue, it’s not quite as expected. Say that a Patron A puts 3 items on a bib record on hold, then Patron B comes along and places 2 of the same items on that bib record on hold. Patron B will show up 4th and 5th in the hold queue, despite being 2nd for two different items. 2. I’m not sure that the drop down is necessary. If a customer wants to place holds, the natural desire would be to either have checkboxes for each individual item and a single hold button or individual hold buttons for each item that would trigger a javascript confirmation rather than a second screen 3. Related, the user has to go back into the record for each item they want to place on hold. This is cumbersome. 4. The actual workflow works more or less as expected. One issue would be when checking out a second item on a bib record to a patron, there is a box that asks to confirm checkout. I think we should have the option to suppress this. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9021] Add SMS via email as an alternative to SMS services via SMS::Send drivers
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9021 --- Comment #86 from M. Tompsett <mtompset(a)hotmail.com> --- Comment on attachment 47133 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=47133 Bug 9021 - Add SMS via email as an alternative to SMS services via SMS::Send drivers Review of attachment 47133: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=902…) ----------------------------------------------------------------- ::: admin/sms_providers.pl @@ +41,5 @@ > + > +my $op = $cgi->param('op'); > +my $id = $cgi->param('id'); > +my $name = $cgi->param('name'); > +my $domain = $cgi->param('domain'); It might be an idea to add '// q{}' to the end of these. -- 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 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15000 --- Comment #7 from Chris Nighswonger <cnighswonger(a)foundations.edu> --- Probably the best resolution is to warn the user about the potential overwrite and let the user decide at that point whether to cancel and rename or proceed and overwrite. Based on experience, it is very nice to be able to simply overwrite an image with a more recent one. However, some users may not anticipate that happening and so a warning needs to be in place. -- You are receiving this mail because: You are watching all bug changes.

1 0