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

[Bug 9996] New: Fix search for existing/upgraded Debian package instances
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9996 Bug ID: 9996 Summary: Fix search for existing/upgraded Debian package instances Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)enger.priv.no CC: robin(a)catalyst.net.nz Depends on: 3087, 9256 Bug 9256 fixed the fallout from bug Bug 3087 for *new* instances that are created with koha-create, but it did nothing for instances that are upgraded to 3.10.x. We probably need a koha-upgrade-to-3.10, similar til how it was done for 3.4? What I found I had to do to make my instances work after they were upgraded from 3.8.11 to 3.10.4 was: 1. Replace syntax="usmarc" with syntax="normarc|marc21" in koha-conf-xml (and by "normarc|marc21" I mean either normarc or marc21, depending on what the instance actually uses) 2. Change this: <xi:include href="/etc/koha/zebradb/retrieval-info-auth-dom.xml" to this: <xi:include href="/etc/koha/zebradb/marc21-retrieval-info-auth-dom.xml" or this: <xi:include href="/etc/koha/zebradb/normarc-retrieval-info-auth-dom.xml" again depending on what marcflavour the instance uses. 3. Restart Zebra So a koha-upgrade-to-3.10 script should probably do something similar. But I might be missing things! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 13109] New: Serial failure for received and general viewing
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13109 Bug ID: 13109 Summary: Serial failure for received and general viewing Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: librarian(a)sasaki.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com For Log Magazine, also still an issue for Sports Business Journal Received the following message Software error: Usage: Date::Calc::Delta_Days(year1, month1, day1, year2, month2, day2) at /usr/share/koha/lib/C4/Serials.pm line 2379. For help, please send mail to the webmaster (staff(a)bywatersolutions.com) giving this error message and the time and date of the error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 13417] New: New permission to allow staff to remove public lists
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13417 Bug ID: 13417 Summary: New permission to allow staff to remove public lists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently a public list can only be deleted by its owner. This means lists can exist infinitely. This will introduce a new permission for list. With this permission, a staff member will be allow to delete any public lists. -- You are receiving this mail because: You are watching all bug changes.

1 63

[Bug 8411] New: merging allows for creation of duplicate fields where not allowed
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8411 Priority: P5 - low Change sponsored?: --- Bug ID: 8411 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: merging allows for creation of duplicate fields where not allowed Severity: critical Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Cataloging Product: Koha See here : http://manual.koha-community.org/3.8/en/stafflists.html#mergebibrecs the merging bib records tool used to stop you from adding fields if they were not repeatable, but I was just able to add the two 001 fields to my destination record but the framework says it's not repeatable. For the 999 it didn't add it but didn't give me an error either. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 7571] New: Maintain exchange rate history
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7571 Bug #: 7571 Summary: Maintain exchange rate history Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: savitra.sirohi(a)osslabs.biz QAContact: koha.sekjal(a)gmail.com Indian libraries need to maintain exchange rates across time. When items are invocied, sometime invoice date can be in the past, the actual cost needs to be calculated using the exchange rate as it stood on the inovice date. With this change Koha will store exchange rates for each currency along with "last update date". Invoicing and receiving pages will be changed to calculate actual cost based on exchange rates as on on invoice dates. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 19

[Bug 5711] New: Distinction between authors/additional authors in opac normal view (MARC21/XSLT)
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5711 Summary: Distinction between authors/additional authors in opac normal view (MARC21/XSLT) Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The patch for bug 5701 put the additional authors with their relator codes on their own line in the staff client and we should do the same in the OPAC. I suggest a further break out that looks like this: Author: Editor: Illustrator: Translator: Additional Authors: Otherwise the editor or translator will appear as an author and that's confusing I think to the patrons. Relator Codes here: http://www.loc.gov/marc/relators/relaterm.html -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 7

[Bug 12481] New: Staff client detail-view "next" link is greyed out when the last search result of any results page is clicked or navigated into
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12481 Bug ID: 12481 Summary: Staff client detail-view "next" link is greyed out when the last search result of any results page is clicked or navigated into Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: jseppal(a)student.uef.fi Reporter: jseppal(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)biblibre.com Blocks: 12261 When doing a staff client catalog search with more than 1 page of results and clicking the last result on any search result page, the top-left navigation button for "next" is greyed out. The expected behaviour would be to move into the next page of results. The "next" navigation should only be prevented when the very last search result is selected in the detail-view. As suggested in the linked bug 12261, this is a regression from my attempt to fix the issue with the navigation letting the user moving out of bound in relation to the result array. As suggested in bug 12261, the original cause was in part due to the total number of results not being carried in the search cookie. Secondly, the offset value that was being used in the navigation checks shouldn't be used in there (the checks for allowing movement within the results) because the cookie value is only updated upon a result click and not when the user is navigating using the detail-view. I wrongly submitted a patch to bug 12261 since it was already pushed. The patch brings the total number of search results available (as I think it was orignally planned, since the non-existing value was being used) to the browser.js which handles the navigation and makes use of that. I marked this as blocking 12261 - not sure if this is right... -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 13265] New: Still too many search cursor cookies
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13265 Bug ID: 13265 Summary: Still too many search cursor cookies Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have multiple sites that are still exhibiting bug 11369. For whatever reason, the cookies on these sites are larger and thus the maximum of 10 is still too large. This setting should be controlled by a system preference to the number can be tailored on a per-site basis. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 7879] New: Memoize::Memcached two times slower than it should be
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7879 Priority: P5 - low Change sponsored?: --- Bug ID: 7879 Assignee: gmcharlt(a)gmail.com Summary: Memoize::Memcached two times slower than it should be QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: dpavlin(a)rot13.org Hardware: All Status: NEW Version: rel_3_6 Component: Architecture, internals, and plumbing Product: Koha Created attachment 8791 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8791&action=edit Memoize::Memcached 2x speedup While profiling Koha with memcached turned on I was stunned by NYTProf results: Calls P F Exclus Inclus Subroutine 55 2 1 1.70s 1.70s Memoize::Memcached::EXISTS 55 2 1 1.68s 1.68s Memoize::Memcached::FETCH Code analysts showed that it generates two FETCH requests for each item. Attached patch fixes upstream module and might be beneficial on existing Koha installations which use memcached. It uses shared variable, and it's safe in CGI installations. Having shared variable showed another characteristic of current code: 55 2 1 33.8ms 33.8ms Memoize::Memcached::EXISTS 55 2 1 362µs 362µs Memoize::Memcached::FETCH This is good, but a little bit too fast. Examining hit and miss ratio stored in Koha::Persistant::stats it turns out that we are accessing memcache 106 times, but only 4 times for new values. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12919] New: It'd be nice to be able to automate collecting all records added and deleted from the catalogue
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12919 Bug ID: 12919 Summary: It'd be nice to be able to automate collecting all records added and deleted from the catalogue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: chris(a)bigballofwax.co.nz QA Contact: testopia(a)bugs.koha-community.org In NZ almost all libraries participate in the National Union Catalogue, which means that libraries have to update their holdings periodically. So we created a system that runs as a cronjob and will generate a list of records added or updated in the catalogue, and a list of isbn of deleted records. These can be run as cron jobs with the output being emailed to a person or thing. Although this was initially designed to support the needs of NZ libraries, it is general enough that it can be used by anyone. -- You are receiving this mail because: You are watching all bug changes.

1 21