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

[Bug 9988] Leave larger authority merges to merge_authorities cronjob ( pref AuthorityMergeLimit)
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 --- Comment #106 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Julian Maurice from comment #102) > 4) Koha::Authorities::get_usage_count and > Koha::Authorities::linked_biblionumbers look very similar. Is there a real > performance gain to use get_usage_count instead of linked_biblionumbers ? > C4::Authorities::merge call them both and it looks like we could save one > search request by calling only linked_biblionumbers Yes, there is a performance gain depending on the number of linked records. A significant difference between both subs is the second and third parameter of the simple_search_compat call. And the biblionumber extraction of course. I first worked with one sub doing both, but in the end I felt that separating them resulted in cleaner code. I would prefer not to change them on this report anymore. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9988] Leave larger authority merges to merge_authorities cronjob ( pref AuthorityMergeLimit)
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 --- Comment #105 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Julian Maurice from comment #103) > 5) When I merge 2 authorities on the staff interface, I get a > UNIMARC-related error: > > Unsupported UNIMARC character encoding [] for XML output for UNIMARCAUTH; > 100$a -> at /usr/share/perl5/MARC/File/XML.pm line 568. > > It's triggered by MARC::Record::as_xml in > Koha::Authority::MergeRequests::reporting_tag_xml. > > It seems to work correctly when I add the following code before as_xml: > > # Copied from AddAuthority > my $date = POSIX::strftime("%Y%m%d", localtime); > my $defaultfield100 = > C4::Context->preference('UNIMARCAuthorityField100'); > $newrecord->append_fields( > MARC::Field->new('100', ' ', ' ' , 'a'=> $date.$defaultfield100) > ); Thanks. This error actually is the same as point 3 of the previous comment. I will add an absolute minimum 100 with encoding only for UNIMARC to resolve the problem in MARC::File::XML. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14590] Validate messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14590 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62043|0 |1 is obsolete| | --- Comment #17 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 62044 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62044&action=ed… Bug 14590: Validate messaging preferences Messaging preferences should be only available if a valid contact information is stored for the patron for that transport type. Otherwise, it should not be possible to select preferences for that transport type. For example, when attempting to set messages to be delivered via sms, we should automatically check patron's smsalertnumber before allowing this type of modification. If patron does not have a valid smsalertnumber and is not passing it along with the messaging preference change, we should not store those given messaging transport types. This patch implements exactly this. It uses Koha::Validation from Bug 14620 to validate contact informations and attaches it into patron modification logic - whenever messaging preferences are processed by Koha, preferences that link to an invalid or non-existent contact information will be removed. Client-side JavaScript checks are also implemented. When modifying patron information, messaging preferences for a certain transport type will be either enabled and/or disabled on the fly depending on validity of the contact info linked to that transport type (transport type "sms" => borrower "smsalertnumber"). TESTING: This feature requires tests both in OPAC and staff client. Requirements: 1. Apply patch(es) in Bug 14620 before this patch 2. Make sure EnhancedMessagingPreferences is enabled 3. Make sure EnhancedMessagingPreferencesOPAC is enabled 4. Make sure TalkingTechItivaPhoneNotification is enabled (activates transport type "phone") 5. Make sure SMSSendDriver is enabled (for simple testing purposes you can use the value "test") 6. Preference "ValidatePhoneNumber" needs a regular expression for validating phone numbers. An example regular expression is provided below the input field. You can use that while testing this feature. Copy-paste it into the input box and save preferences. (regex also provided below) ^((\+)?[1-9]{1,2})?([-\s\.])?(($\d{1,4}$)|\d{1,4})(([-\s\.])?[0-9]{1,12}){1,2}$ TEST PLAN: 1. Login to staff client 2. Go to modification view of any patron 3. Scroll down all the way and you should see "Patron messaging preferences" table including checkboxes for transport types "SMS", "Phone" and "Email". 4. If the patron you are modifying has any contact information of the following "Primary email", "Primary phone", "SMS number", please clear those fields. 5. Scroll down. All checkboxes for the given transport types should now be disabled. 6. Modify field "Primary email" and insert "test". A warning of invalid email should appear. 7. Scroll down. Checkboxes for transport type "Email" should still be disabled. 8. Modify field "Primary email" and insert "nobody(a)example.com". 9. Scroll down. Checkboxes for transport type "Email" should now be enabled. 10. Select email as transport type for each message type and click "Save". 11. Go back to modification screen. The messaging preferences should still appear as you stored them. 12. Repeat steps 6-11 also for both "Phone" and "SMS number". When inserting text into phone number fields, they should appear as invalid, so test like that. 13. After successful testing, test also other patron modification screens. Go to patron's Details tab and you should see multiple "Edit" links on that page. The point is to make sure transport type selections are correctly removed from the patron if the modification screen lets you modify for example primary email, but does not present the messaging preferences at the bottom of the page. So, as an example, first insert patron a valid email and select all email transport types. Then, go to the "Edit" link right above "Patron messaging preferences" title on patron's details page. This page lets you modify "Primary email" but not messaging preferences. Clear the "Primary email" field and save, and observe that all previously selected email transport types are now removed. 14. Give your patron a valid email and go to Details tab -> "Edit" link below "Patron messaging preferences title" on the left. You should still be able to select email as transport types. 15. Go remove patron's primary email and repeat step 14. You will observe that it is no longer possible to select email as a transport type. 16. Try steps 13-15 with other transport types as well After this test plan you should have a pretty good idea of the feature. As mentioned earlier, this feature requires tests on the OPAC side as well. So attempt this also via OPAC and make sure preferences are validated when the librarian approves patron's modifications. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14590] Validate messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14590 --- Comment #16 from Lari Taskula <lari.taskula(a)jns.fi> --- Rebased on master & rewrote much of the patch and added a more detailed test plan. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14606] Donate to the Koha International Fund
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14606 Pablo AB <pablo.bianchi(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pablo.bianchi(a)gmail.com --- Comment #15 from Pablo AB <pablo.bianchi(a)gmail.com> --- Right now I get an error using donate button: "Error Detected: PayPal cannot process this transaction because of a problem with the seller's website. Please contact the seller directly to resolve this problem." I'd be less shy about this subject, like Wikipedia or Canonical. Why not a Donate button in the black menu top bar? BTW, why not also offer some other alternatives? - A donation site better than Paypal: donorbox.org, bountysource.com, liberapay.com, patreon.com. - QR code to donate to a Bitcoin wallet. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14590] Validate messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14590 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #62040|0 |1 is obsolete| | --- Comment #15 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 62043 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62043&action=ed… Bug 14590: Validate messaging preferences Messaging preferences should be only available if a valid contact information is stored for the patron for that transport type. Otherwise, it should not be possible to select preferences for that transport type. For example, when attempting to set messages to be delivered via sms, we should automatically check patron's smsalertnumber before allowing this type of modification. If patron does not have a valid smsalertnumber and is not passing it along with the messaging preference change, we should not store those given messaging transport types. This patch implements exactly this. It uses Koha::Validation from Bug 14620 to validate contact informations and attaches it into patron modification logic - whenever messaging preferences are processed by Koha, preferences that link to an invalid or non-existent contact information will be removed. Client-side JavaScript checks are also implemented. When modifying patron information, messaging preferences for a certain transport type will be either enabled and/or disabled on the fly depending on validity of the contact info linked to that transport type (transport type "sms" => borrower "smsalertnumber"). TESTING: This feature requires tests both in OPAC and staff client. Requirements: 1. Apply patch(es) in Bug 14620 before this patch 2. Make sure EnhancedMessagingPreferences is enabled 3. Make sure EnhancedMessagingPreferencesOPAC is enabled 4. Make sure TalkingTechItivaPhoneNotification is enabled (activates transport type "phone") 5. Make sure SMSSendDriver is enabled (for simple testing purposes you can use the value "test") 6. Preference "ValidatePhoneNumber" needs a regular expression for validating phone numbers. An example regular expression is provided below the input field. You can use that while testing this feature. Copy-paste it into the input box and save preferences. (regex also provided below) ^((\+)?[1-9]{1,2})?([-\s\.])?(($\d{1,4}$)|\d{1,4})(([-\s\.])?[0-9]{1,12}){1,2}$ TEST PLAN: 1. Login to staff client 2. Go to modification view of any patron 3. Scroll down all the way and you should see "Patron messaging preferences" table including checkboxes for transport types "SMS", "Phone" and "Email". 4. If the patron you are modifying has any contact information of the following "Primary email", "Primary phone", "SMS number", please clear those fields. 5. Scroll down. All checkboxes for the given transport types should now be disabled. 6. Modify field "Primary email" and insert "test". A warning of invalid email should appear. 7. Scroll down. Checkboxes for transport type "Email" should still be disabled. 8. Modify field "Primary email" and insert "nobody(a)example.com". 9. Scroll down. Checkboxes for transport type "Email" should now be enabled. 10. Select email as transport type for each message type and click "Save". 11. Go back to modification screen. The messaging preferences should still appear as you stored them. 12. Repeat steps 6-11 also for both "Phone" and "SMS number". When inserting text into phone number fields, they should appear as invalid, so test like that. 13. After successful testing, test also other patron modification screens. Go to patron's Details tab and you should see multiple "Edit" links on that page. The point is to make sure transport type selections are correctly removed from the patron if the modification screen lets you modify for example primary email, but does not present the messaging preferences at the bottom of the page. So, as an example, first insert patron a valid email and select all email transport types. Then, go to the "Edit" link right above "Patron messaging preferences" title on patron's details page. This page lets you modify "Primary email" but not messaging preferences. Clear the "Primary email" field and save, and observe that all previously selected email transport types are now removed. 14. Give your patron a valid email and go to Details tab -> "Edit" link below "Patron messaging preferences title" on the left. You should still be able to select email as transport types. 15. Go remove patron's primary email and repeat step 14. You will observe that it is no longer possible to select email as a transport type. 16. Try steps 13-15 with other transport types as well After this test plan you should have a pretty good idea of the feature. As mentioned earlier, this feature requires tests on the OPAC side as well. So attempt this also via OPAC and make sure preferences are validated when the librarian approves patron's modifications. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15395] Allow correct handling of plural translation
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15395 --- Comment #35 from Julian Maurice <julian.maurice(a)biblibre.com> --- Created attachment 62041 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62041&action=ed… Bug 15395: Search .js files in more directories Specifically, koha-tmpl/intranet-tmpl/prog/js and koha-tmpl/opac-tmpl/bootstrap/js -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14590] Validate messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

1 0

[Bug 14590] Checkboxes should be disabled without valid contact information in messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14590 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44704|0 |1 is obsolete| | --- Comment #14 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 62040 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62040&action=ed… Bug 14590: Validate messaging preferences Messaging preferences should be only available if a valid contact information is stored for the patron for that transport type. Otherwise, it should not be possible to select preferences for that transport type. For example, when attempting to set messages to be delivered via sms, we should automatically check patron's smsalertnumber before allowing this type of modification. If patron does not have a valid smsalertnumber and is not passing it along with the messaging preference change, we should not store those given messaging transport types. This patch implements exactly this. It uses Koha::Validation from Bug 14620 to validate contact informations and attaches it into patron modification logic - whenever messaging preferences are processed by Koha, preferences that link to an invalid or non-existent contact information will be removed. Client-side JavaScript checks are also implemented. When modifying patron information, messaging preferences for a certain transport type will be either enabled and/or disabled on the fly depending on validity of the contact info linked to that transport type (transport type "sms" => borrower "smsalertnumber"). TESTING: This feature requires tests both in OPAC and staff client. Requirements: 1. Apply patch(es) in Bug 14620 before this patch 2. Make sure EnhancedMessagingPreferences is enabled 3. Make sure EnhancedMessagingPreferencesOPAC is enabled 4. Make sure TalkingTechItivaPhoneNotification is enabled (activates transport type "phone") 5. Make sure SMSSendDriver is enabled (for simple testing purposes you can use the value "test") 6. Preference "ValidatePhoneNumber" needs a regular expression for validating phone numbers. An example regular expression is provided below the input field. You can use that while testing this feature. Copy-paste it into the input box and save preferences. (regex also provided below) ^((\+)?[1-9]{1,2})?([-\s\.])?(($\d{1,4}$)|\d{1,4})(([-\s\.])?[0-9]{1,12}){1,2}$ TEST PLAN: 1. Login to staff client 2. Go to modification view of any patron 3. Scroll down all the way and you should see "Patron messaging preferences" table including checkboxes for transport types "SMS", "Phone" and "Email". 4. If the patron you are modifying has any contact information of the following "Primary email", "Primary phone", "SMS number", please clear those fields. 5. Scroll down. All checkboxes for the given transport types should now be disabled. 6. Modify field "Primary email" and insert "test". A warning of invalid email should appear. 7. Scroll down. Checkboxes for transport type "Email" should still be disabled. 8. Modify field "Primary email" and insert "nobody(a)example.com". 9. Scroll down. Checkboxes for transport type "Email" should now be enabled. 10. Select email as transport type for each message type and click "Save". 11. Go back to modification screen. The messaging preferences should still appear as you stored them. 12. Repeat steps 6-11 also for both "Phone" and "SMS number". When inserting text into phone number fields, they should appear as invalid, so test like that. 13. After successful testing, test also other patron modification screens. Go to patron's Details tab and you should see multiple "Edit" links on that page. The point is to make sure transport type selections are correctly removed from the patron if the modification screen lets you modify for example primary email, but does not present the messaging preferences at the bottom of the page. So, as an example, first insert patron a valid email and select all email transport types. Then, go to the "Edit" link right above "Patron messaging preferences" title on patron's details page. This page lets you modify "Primary email" but not messaging preferences. Clear the "Primary email" field and save, and observe that all previously selected email transport types are now removed. 14. Give your patron a valid email and go to Details tab -> "Edit" link below "Patron messaging preferences title" on the left. You should still be able to select email as transport types. 15. Go remove patron's primary email and repeat step 14. You will observe that it is no longer possible to select email as a transport type. 16. Try steps 13-15 with other transport types as well After this test plan you should have a pretty good idea of the feature. As mentioned earlier, this feature requires tests on the OPAC side as well. So attempt this also via OPAC and make sure preferences are validated when the librarian approves patron's modifications. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14590] Checkboxes should be disabled without valid contact information in messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14590 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0