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

[Bug 11897] Stock Rotation for Koha
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11897 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #54 from Owen Leonard <oleonard(a)myacpl.org> --- Testing again I can't reproduce the error. I will continue to look. -- 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 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #108 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Back to SO queue -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12026] Shibboleth auto-provisioning
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12026 --- Comment #89 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- You're totally right Katrin, I should expand the documentation a bit here. This patch was only ever intended to 'add new' user record (i.e to 'provision') and not to 'sync'. To be honest, I'd love to also submit a 'sync' patch and include an option to only sync certain fields but I'd likely need a bit of sponsorship to get that through. I'm happy to code it up, but it's a nightmare to get these patches through signoff and qa ;) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11897] Stock Rotation for Koha
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11897 --- Comment #53 from Alex Sassmannshausen <alex.sassmannshausen(a)ptfs-europe.com> --- Hi Owen, I've been trying to reproduce this, but cannot. (In reply to Owen Leonard from comment #52) > Everything was working up until just after adding a list of barcodes to a > rota. When I try to go back to 'manage items' I get an error: > > Proxy Error > > The proxy server received an invalid response from an upstream server. > The proxy server could not handle the request GET > /cgi-bin/koha/tools/stockrotation.pl. Is this a persistent error? When you say you try to go back to 'manage items' does this mean you succesfully get to the rotas overview screen, but when you click on 'manage' for the rota you just added the items to, and then 'items', that's when the error appears? There should be no proxying going on here… What testing environment are you using? Is it a devbox? If so, is it with Plack switched on? Would you be able to retest this particular operation with Plack switched off? Thanks for testing so far! Alex -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 Daphne Hoolahan <dch(a)interleaf.ie> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dch(a)interleaf.ie --- Comment #22 from Daphne Hoolahan <dch(a)interleaf.ie> --- It all went pretty good and worked fine. We just found a couple of things that are worth pointing out: 6.1.1 – Why is the biblio number empty on this screen? Actually one of them has the value zero now that we went through the whole process. 6.1.2 – we noticed that we could request the same title more than once. Maybe not an issue but worth mentioning. 6.1.9 – we received the email fine but it does not say who it is from, ther than it has the from email address. Should it have the from organisation above the status or is the staff member expected to customise the email text to indicate their organisation? Dear Sir/Madam, We would like to request an interlibrary loan for a title matching the following description: - Status: New - Author: A.N. Other - ID: 5678 - Title: Interlibrary loans in Koha Please let us know if you are able to supply this to us. Kind Regards 6.2 – We found it difficult to find any matching titles. What is keywords for? (especially as title has a separate entry field) image attached Also we got an error when we tried this search – didn’t seem to like the book filter: Error performing operation image attached When trying to confirm a request from the BL Software error: The API responded with an error: 500 Internal Server Error Detail: <?xml version="1.0" encoding="UTF-8"?><apiResponse><timestamp>2017-03-28 13:15:56.941 BST</timestamp><status>8</status><message>Authentication failed: Exception occurred processing authentication, please contact BL Customer Services</message><result /></apiResponse> at /usr/share/koha-interleaf/Koha/Illbackends/BLDSS/Base.pm line 481. For help, please send mail to the webmaster (alex.sassmannshausen(a)ptfs-europe.com) giving this error message and the time and date of the error. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12026] Shibboleth auto-provisioning
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12026 --- Comment #88 from Zeno Tajoli <z.tajoli(a)cineca.it> --- Hi Katrin, in fact to answer your question you need to read also the code. I do some answers: >Is there documentation about this new feature available somewhere? The documentation is inside C4/Auth_with_shibboleth.pm in POD format. To see it: perldoc C4/Auth_with_shibboleth.pm >Is it possible to choose if you want to add a new user and update existing users like it is with LDAP? No. The system only adds a new user, it does not update an existing user. And it adds a new user only when, inside login process, it finds that there isn't an existing user with userid = the shibboleth attribure defined with this XML in koha-conf.xml: <matchpoint>userid</matchpoint> <mapping> <userid is="uid"></userid> </mapping> >Do the attributes have to match exactly to what Koha expects (branchcode, categorycode specifically) or is there a way to do a mapping? You can mapping using koha-conf.xml. This is an example: <matchpoint>userid</matchpoint> <mapping> <userid is="uid"></userid> <surname is="sn"></surname> <categorycode is="tip"></categorycode> <branchcode is="cod"></branchcode> <email is="uid"></email> <emailpro is="mail"></emailpro> </mapping> The <matchpoint> ... </matchpoint> and the connected attribute are clearly mandatory. Also attributes for categorycode and branchcode are mandatory, I think. Ohters are optional. Bye -- 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 12 Apr '17

12 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 #62044|0 |1 is obsolete| | --- Comment #18 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 62071 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62071&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 13501] Allow autocompletion on drop-down lists
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13501 Oleg Vasilenko <synapse.ova(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18422 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18422 [Bug 18422] Add Select2 to authority editor -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12026] Shibboleth auto-provisioning
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12026 --- Comment #87 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Actually, after looking at the POD, I am still not sure what is the answer to my questions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12026] Shibboleth auto-provisioning
by bugzilla-daemon＠bugs.koha-community.org 12 Apr '17

12 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12026 --- Comment #86 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Thx Zeno - I looked at the patches, but didn't spot it! -- You are receiving this mail because: You are watching all bug changes.

1 0