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

[Bug 15153] New: Koha::DateUtils sub dt_from_string has two different functions
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15153 Bug ID: 15153 Summary: Koha::DateUtils sub dt_from_string has two different functions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: j.kylmala(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::DateUtils sub dt_from_string has two different functions: get date from string and return DateTime->now(). I think it would be better to seperate to other subroutine or remove fully the DateTime->now() because if someone uses dt_from_string in code to generate the date now it would be really hard for others to understand what is happening because the subroutine's name doesn't give any clues. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] New: Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 Bug ID: 14723 Summary: Additional delivery notes to messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Currently at message_queue we are given only two delivery statuses for messages, "sent" and "failed". When the status becomes failed, we have no idea why it fails. Some SMS gateway providers send the customer a report about the status of delivery. For example, in our local library we have a provider that does this. With the SMS HTTP request to their Gateway, we also provide them a "report" parameter that includes an URL. Once the SMS delivery has been finished, they will notify us with the status to the given report URL. If they notify us that the delivery was failed, we will modify its status in the database accordingly. They also provide a short description of why the delivery was failed. To be able to store more detailed information about the delivery, I propose adding a new column (e.g "delivery_notes") to message_queue table. In our local library we sometimes have angry borrowers complaining that they have not received SMS messages, so this type of enhancement would be very useful to be able to find out why such has happened. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 10450] New: Editing serials predicts wrong
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10450 Bug ID: 10450 Summary: Editing serials predicts wrong Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: colin.campbell(a)ptfs-europe.com I have seen this happen since Koha 3.8 but thought it was just me - now I'm going to report a bug in case someone can track down the problem. Here's an example: ---- I have the July issue of Food & Wine in hand. I am in the Food & Wine serials record and filling in the date of next publication and the '# starts with' for predictions. I put 07/01/2013 for next publication and I put a 7 in the predictions chart (since I am starting these records off now) But when I go to check in the July issue, it gives 2013:8 for the issue and publication date as 08/01/2013. ---- This always happens when you edit an existing serial record's prediction pattern. No matter what you put in it always generates the next one - not the one you entered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 14820] New: SMSSendUsername and SMSSendPassword are not listed in the system preferences
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14820 Bug ID: 14820 Summary: SMSSendUsername and SMSSendPassword are not listed in the system preferences Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle.m.hall(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Although SMSSendDriver is listed in the system preferences, neither SMSSendUsername not SMSSendPassword are even though they are used to pass the username and password to the driver! -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 15145] New: Fix hover state on bugzilla theme header so it doesn't jump on hover
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15145 Bug ID: 15145 Summary: Fix hover state on bugzilla theme header so it doesn't jump on hover Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Websites, Mailing Lists, etc Assignee: francescalamoore(a)gmail.com Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The new theme is very cheerful, it would be nice if the header didn't jump when you hovered over the header text. Also possibly consider setting the fonts from serif to Arial, Helvetica, sans-serif in the bugzilla theme. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14744] New: Cannot select guarantor when quote in one of the fields
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14744 Bug ID: 14744 Summary: Cannot select guarantor when quote in one of the fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a field (here it's the branch name) contains a quote, the Select button doesn't work in guarantor_search.pl. For example, if our branch is "Bibliothèque d'Avignon", the resulting json in the link is all broken and the "select" does nothing. Setup: - Have a Child patron and Adult patron in your DB. - In Admin/Libraries and Group, modify the name to add a ' in the middle. Test: - Modify your child patron. - The second section should be "Guarantor Information" - Click the "Set to patron" button - Enter the info to find your adult - In the resulting list, click the Select at the end of the line - Nothing will happen - Hover over the link, you'll see the gibberish inside. - Remove the ' from the branch name. Do the steps above. Everything is alright. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 11496] New: The number of tested records when searching for duplicates during import is too low
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11496 Bug ID: 11496 Summary: The number of tested records when searching for duplicates during import is too low Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, only the first 10 records returned by koha for a given matchpoint are tested. This is not enough in some cases, because a significant matching record can be beyond these 10 first results. Please note that when the checkpoint is about fields with unique identifiers, like ISBN, the problem won't occur. On the other hand, when the checkpoint is about something less precise, like an author name, the matching record can be beyond the 10 first results. When that happens, the matchpoint will fail, the match threshold won't be reached, and a duplicate record will be created. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 13391] New: MARC 008 builder plugin not compatible with browser autocompletion
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13391 Bug ID: 13391 Summary: MARC 008 builder plugin not compatible with browser autocompletion Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the koha-tmpl/intranet-tmpl/prog/en/js/xmlControlfield.js (line 317) there are two JS events (onkeyup and onfocus) being handled for 008 MARC plugin <input ...> fields (for MARC21 008 plugin, <input> is used e.g. for dates, country codes and language codes). But there is a slight problem with onkeyup event handler: apparently this event does not fire when: - user starts to enter some characters using the keyboard, - and then chooses something from the autocompletion list offered by browser. End result is that in such circumstances only the first character[s] entered in the given field are saved in 008 (only the part that was typed on the keyboard), and the remaining characters are effectively lost / being ignored by 008 plugin (unless the user "returns" to this field, i.e. gives it focus once again, before clicking "OK"). Replacing 'onkeyup' with 'oninput' in line 317 looks like the easiest solution for this issue; it works fine in recent (HTML5 compliant) browsers, but OnInput event handler is relatively new thing - it would not work in old, "legacy" WWW browsers. I guess we can also add autocomplete='off' to the <input> fields generated by renderPositions() function in xmlControlfield.js ;). I'm wondering what would happen if we try to put both oninput=.. and onkeyup= event handlers in those fields (probably both of them would fire when user enters something, but maybe that will be not necessarily such a bad thing ?). However, none of those methods are quite sufficient for older browsers. Reparsing all fields on form submit may help a little bit - so changes in the entered values which may have been previously ignored by the plugin would have a chance to be saved in 008 after all - but that's only a partial solution, the 008 contents being displayed on top may still sometimes get "out of sync" with the individual values below.. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 15106] New: Batch Patron Modification Performance Improvement
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '15

06 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15106 Bug ID: 15106 Summary: Batch Patron Modification Performance Improvement Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cnorthcott.work(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Blocks: 7923 Batch Patron Modification has a fairly long run/load time. I have attempted to improve the runtime of the Batch Patron Modification tool and my enhancement reduces the time to modify a batch of patrons by an average of 44.02% I discovered the extended runtime was mostly due to detailed data retrieval in preparation for display. The overhead for a batch of 1000 patrons was enough that I have changed functionality so that if there are more than 20 patrons in the batch to simply display a success message instead of the details of every changed patron. There are other small code logic improvements also included to prevent unnecessary function calls. In the end my test case of 1000 patrons originally took 59.02 seconds to modify, after optimisation it took 33.04 seconds saving 25.98 seconds. Referenced Bugs: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7923 [Bug 7923] Performance omnibus -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 13435] New: OPAC self registration can't find OPAC_REG_VERIFY notice if it is assigned to a branch
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '15

05 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13435 Bug ID: 13435 Summary: OPAC self registration can't find OPAC_REG_VERIFY notice if it is assigned to a branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Email verification can look very broken for multi branch systems - if there is no "all libraries" notice defined for "OPAC_REG_VERIFY," but one defined for a specific branch, the self registration code can't find the notice and thus the verification email is not sent. Additionally, this code will only ever return the "all libraries" version of this notice, as it never passes a branchcode - making this notice useless on a per-branch basis. -- You are receiving this mail because: You are watching all bug changes.

1 2