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

[Bug 9434] New: Static variables used for caches are not Plack-friendly
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '15

17 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9434 Bug ID: 9434 Summary: Static variables used for caches are not Plack-friendly Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jcamins(a)cpbibliography.com At the moment we cache numerous pieces of information in module-level variables which then do not get updated in other threads/processes when they are changed by the user. This is a serious usability issue. Examples of this include the way we treat sysprefs (there is now a method to disable the syspref cache, but by default it is enabled), notices, frameworks, field mappings, and koha-conf.xml, at least. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 14549] New: Reserve not removed when issued to member that is not in Priority # 1 position and comes via the “invalid” reserve queue
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '15

17 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14549 Bug ID: 14549 Summary: Reserve not removed when issued to member that is not in Priority # 1 position and comes via the “invalid” reserve queue Change sponsored?: --- Product: Koha Version: 3.14 Hardware: PC OS: Windows Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: amanda.kelly(a)charteredaccountantsanz.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 41048 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41048&action=edit shows AU member is Priority #1 and NZ member in #2 position This is not the issue described in this bug: (2830 Hold not removed when "trapped" item on hold shelf is checked out to a different patron in the holds queue http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2830 / [Signed off] bug_2830: Remove reserve when checking out if the borrower is not the first one in the reserve queue (13.54 KB, patch) 2011-11-17 16:57 UTC, Liz Rea http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6329 ) It is a new “bug” that comes about, I believe, because we have an “invalid” reserves queue. We have a library in Australia and a library in New Zealand. We have merged our biblio records and commissioned work to make Koha differentiate between a reserve placed by an AU member and a reserve placed by a NZ member. They sit in the one reserve queue and are numbered 1,2,3 with the Pickup Library matched to where the member lives. The system knows to match AU book with AU member and same with NZ. All works perfectly fine when the reserve is known because the book is returned– this flags that a reserve is waiting and we confirm the reserve. The problem occurs because we have a new feature called the “Invalid Reserves Queue”. It is a report to show where a reserve is a mismatch, ie. An AU member reserves a NZ book and vice versa. So problem occurs when the reserve is found via the “Invalid Reserves Queue" then it behaves differently. If it is a NZ book we choose the next NZ member. However because they are not in Priority # 1 the reserve remains behind even though we have issued the book to them. So it is similar to these other bugs in that the checkout of the book does not remove the reserve because it is not in Priority No. 1 but it only happens if the reserve comes up via the Invalid queue as it works perfectly fine in all other circumstances. Hoping there are libraries that operate in this fashion and if so has anyone seen and resolved this issue? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14537] New: The system preference 'OverdueNoticeBcc' is mis-named.
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '15

16 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14537 Bug ID: 14537 Summary: The system preference 'OverdueNoticeBcc' is mis-named. 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The system prefrerence 'OverdueNoticeBcc' seems, by its name, to imply that a BCC will be added to all overdue notices -- the description says that the address will be added to all notices. The behavior of the system follows the description, not the system preference name. The system preference should be re-named to NoticeBcc. See also * bug 12490 * discussion on the topic in #koha: http://irc.koha-community.org/koha/2015-07-16#i_1703637 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10148] New: 007/006 not filling in with existing values
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '15

16 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10148 Bug ID: 10148 Summary: 007/006 not filling in with existing values Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com CC: m.de.rooy(a)rijksmuseum.nl When you use the 007 builder to view the existing values in the 007 tag, Koha is not pulling these existing values into the builder window. Instead, Koha appears to be using defaults. For example: 1. Open a record in the editor 2. The existing fixed field values in the 007 tag are: vd || || 3. Using the tag editor, open the 007 tag builder window and you will see that Koha is not dsiplaying the existing values. 4.If you click the OK button Koha enters the following values: vc aa ak The problem also exists in the 006 tag as well. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 14489] Software error when trying to create new batch
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '15

16 Jul '15

1 0

[Bug 2422] Cataloging searches with more than 1 page results show blank pages after page 1
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '15

16 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2422 --- Comment #7 from Nicholas van Oudtshoorn <vanoudt(a)gmail.com> --- (In reply to Jonathan Druart from comment #5) > On http://library.pbc.wa.edu.au/cgi-bin/koha/opac-search.pl: "using Koha > 3.14.1", is it correct? No! That needs fixing - thanks for pointing it out! :-) We're running a pretty stock install; the only big change we've made is to implement bug 10988 (Google OAuth2 logins for our students). I'm not in at that job until next week again. I'll see about getting some more details or a test instance or something up then. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10994] New: Email sending is not working in claim notice
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '15

15 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10994 Bug ID: 10994 Summary: Email sending is not working in claim notice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org >From address is null acquisitions claim and serial notice. my $userenv = C4::Context->userenv; $userenv->{emailaddress} -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 14372] New: Error font in Koha Vietnamese
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '15

15 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14372 Bug ID: 14372 Summary: Error font in Koha Vietnamese Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hien.pham(a)dlcorp.com.vn QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 40058 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40058&action=edit Font error image While I renew items on Koha, the font error occurred in renewal. Please check help me this error -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 13469] New: Unapi path to XSLTs is wrong in OPAC
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '15

15 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13469 Bug ID: 13469 Summary: Unapi path to XSLTs is wrong in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, Unapi points to C4::Context->config('intranetdir')."/koha-tmpl/intranet-tmpl/prog/en/xslt/". However, it should point to C4::Context->config('intrahtdocs')."/prog/en/xslt/". The first path is set up just to work with a Git install, while the latter will work on every install. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 13922] New: MODS Export Broken on Package
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '15

15 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13922 Bug ID: 13922 Summary: MODS Export Broken on Package Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, oleonard(a)myacpl.org When trying to export using MODS you will get this error: Software error: Can't locate object method "code" via package "Could not create file parser context for file "/usr/share/koha/intranet/cgi-bin/koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2MODS.xsl": No such file or directory at /usr/share/koha/opac/cgi-bin/opac/unapi line 207. " (perhaps you forgot to load "Could not create file parser context for file "/usr/share/koha/intranet/cgi-bin/koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2MODS.xsl": No such file or directory at /usr/share/koha/opac/cgi-bin/opac/unapi line 207. "?) at /usr/share/koha/opac/cgi-bin/opac/unapi line 150. It looks like a path issue. It is looking for: /usr/share/koha/intranet/cgi-bin/koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2MODS.xsl But the correct path appears to be: /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/xslt/MARC21slim2MODS.xsl The incorrect path does appear to be a mix of package and git paths. -- You are receiving this mail because: You are watching all bug changes.

1 3