March 2014 - Koha-bugs - lists.koha-community.org

[Bug 10762] New: Not able to adjust size of barcode numbers
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '15

17 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 Bug ID: 10762 Summary: Not able to adjust size of barcode numbers Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: jesse(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I created a new layout (section 2.5.3.1 in the manual) that just shows the barcode, and I set the font size big. First I did 14, then 32 just to make sure my eyes weren't deceiving me. The numbers below the barcode didn't change size! It seems like the font settings only affect the bibliographic data. What I want to change is the barcode number itself. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 8089] New: Use Koha::Cache everywhere
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '15

17 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8089 Priority: P5 - low Change sponsored?: --- Bug ID: 8089 Assignee: gmcharlt(a)gmail.com Summary: Use Koha::Cache everywhere Severity: enhancement Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Depends on: 7248 Product: Koha -- You are receiving this mail because: You are watching all bug changes.

1 65

[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 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 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 10555] New: overdue_notices -h does not list all options
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '15

15 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10555 Bug ID: 10555 Summary: overdue_notices -h does not list all options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr perl overdue_notices -h does not list all options. The following options are not listed : -v -list-all -t -date M. Saby -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 11112] New: Koha::Calendar->new loads all holidays
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11112 Bug ID: 11112 Summary: Koha::Calendar->new loads all holidays Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Each time a new Koha::Calendar is created, all holidays are retrieved from the DB. On a 3.8 installation, with 11000 holidays and without caching system, a checkin is extremely slow. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 5515] New: Leading 'and' in search never returns a result
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5515 Summary: Leading 'and' in search never returns a result Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: bob-ewart(a)bobsown.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Searching on "and the band played on" returns no results. There are 3 biblios for that title, a book, a DVD and a video. The error log shows: [Thu Dec 16 17:18:27 2010] [error] [client 127.0.0.2] [Thu Dec 16 17:18:27 2010] search.pl: WARNING: query problem with kw,wrdl,rtrn=and band played ZOOM error 10014 "CCL parsing error" (addinfo: "Search word expected") from diag-set 'ZOOM' at /usr/share/koha/lib/C4/Search.pm line 346., referer: http://127.0.0.2:8080/cgi-bin/koha/mainpage.pl This happens with Koha 3.02.01 on openSUSE 11.3 (32-bit and 64-bit) and on Debian squeeze/sid (64-bit) with zebra. Searching on 'the band played on' gets all three records. -- 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 10

[Bug 8697] New: slips not using custom lists on all pages
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8697 Priority: P5 - low Change sponsored?: --- Bug ID: 8697 Assignee: koha-bugs(a)lists.koha-community.org Summary: slips not using custom lists on all pages Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Notices Product: Koha When on the patron record on the Details or Fines tab if you choose to print slip or quick slip it chooses the 'all libraries' slip. Other tabs - like the checkout tab use the custom slip for that branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 6976] New: User hold limit can be avoided by users in OPAC
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6976 Bug #: 6976 Summary: User hold limit can be avoided by users in OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Problem as reported: borrowers are only allowed 5 holds. If holds are done individually, it is obeying that law i.e. X has held 5 separate books – when I tried to do a 6th book it told me that I could not place a hold. However, if a borrower checks the catalogue, gets the intial list up and clicks items on the “results” box and then clicks “place hold” they can hold more than 5 items – I have been able to hold 8 (and I suspect could do more) Looks like the logic is a bit flawed when placing multiple holds as the variable canreserve is not reset for each iteration of the loop. Testing fix on site patch to follow -- 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 37