June 2013 - Koha-bugs - lists.koha-community.org

[Bug 8375] New: Common diacritics not shown correctly when exporting batch label to PDF
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '15

10 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8375 Priority: P5 - low Change sponsored?: --- Bug ID: 8375 Assignee: cnighswonger(a)foundations.edu Summary: Common diacritics not shown correctly when exporting batch label to PDF Severity: normal Classification: Unclassified OS: Linux Reporter: matted-34813(a)mypacks.net Hardware: PC Status: NEW Version: unspecified Component: Label printing Product: Koha When exporting a PDF for labels, many common diacritics display as 2 unrelated characters. ----------------- Steps to reproduce bug: a) setup a koha test environment b) get a record with a diacritic in your system catalogue search -> Z3950 search -> Author: jurgen -> select the record matching the one i selectd above (jahre) -> save record -> add item -> wait for zebra to index (5min) -> catalog serach: jahre c) generate a label batch more -> tools -> label creator -> batch -> new -> add item -> title: jahre -> select and add checked (select library if not already set) d) export as PDF select record -> export batch -> export as PDF e) open and view PDF (zoom as necessary) (you can select text with PDF viewer and cut to cllipboard if needed) Actual Results: Example PDF output that I cut and pasted: 1150Jahre MarkÃ¶bel, 850 Jahre BaiersrÃ¶derhof 3886542378 Books 943/.416 Expected Results: The output should have the diacritic for ö correctly displayed. 1150 Jahre Marköbel, 850 Jahre Baiersröderhof Build Date & Platform: master 2012-07-05 on Debian Squeeze Linux 2.6.32 Additional Information: Refer to my detailed efforts in bug 2246. There were too many different target solutions, so I broke the specific behavior out in this new bug. -- You are receiving this mail because: You are watching all bug changes.

1 125

[Bug 6499] New: OCLC # Indexing & Matching
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6499 Bug #: 6499 Summary: OCLC # Indexing & Matching Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com I know that anyone can add indexes and matching rules, but recently we have gotten many more libraries asking for indexes and matching rules on OCLC number (Marc21 035). This enhancement request is me asking if we could get these added in as defaults. -- 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

[Bug 9593] New: Prices not imported correctly from a staged file
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9593 Bug ID: 9593 Summary: Prices not imported correctly from a staged file Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr Created attachment 15269 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15269&action=edit Prices not imported correctly from a staged file When importing a record from a staged file, sometimes, the price is set to 0 in the Vendor price field (Accounting details block) even if initially present. it occurs when the price is written without decimals : example : 19 EUR. In this case it's not captured by the regular expression in MungeMarcPrice routine (Biblio.pm) : ( $price ) = $price =~ m/([\d\,\.]+[[\,\.]\d\d]?)/; Same thing if the currency symbol was used after the digits, the result would be the same because of this : $price = $parts[1]; If I got it well, seems that the whole routine can be replaced by 2 regular expressions (may be we could even go up to a single one) integrated in GetMarcprice : the first part (symbol treatment) is unusefull as it can be treated directly by the regular expression that's following it. The part concerning groups of more than 2 digits ( if I got it, it 's come out to delete the eventual separator between thousands and hundreds) can be replaced by another regular expression. Test Plan : 1) get on your pc, the joined example file (testfile.elc). That's the kind of file most currently used in France for our acquisitions. Most of the prices in it match the pattern '[digit][digit] EUR' except 2 titles out of them : La méthodologie appliquée du commentaire de texte (14,20 EUR) Le tournant artiste de la littérature française (54,80 EUR) 2) Go to Tools/Stage MARC records for import and stage it in koha. 3) Go to Acquisition module, and an open basket of your choice and click on 'From a staged file' 4) Choose testfile.elc and add it to the basket 5) Click on the first individual 'add order' link : the price might beeing set to 00.00 in the 'Vendor price' field of Accounting details block. 6) Now go back with go back function of your browser : 7) Apply the patch 8) Click again on the same link 9) The price is now present (I hope so) 10 Sign off (I hope so again) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 105

[Bug 7957] New: Routing lists: manage several routing list for each subscription, and export them as CSV
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '15

07 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7957 Priority: P5 - low Change sponsored?: Sponsored Bug ID: 7957 Assignee: julian.maurice(a)biblibre.com Summary: Routing lists: manage several routing list for each subscription, and export them as CSV QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: julian.maurice(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Serials Product: Koha This development will allow to create more than one routing list for each subscription. There will be a new page for managing them (create, edit, delete), printing them, and exporting them as CSV. -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 8754] New: Cardnumber/accession number range when creating print batches in tools
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '15

06 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8754 Priority: P5 - low Change sponsored?: --- Bug ID: 8754 Assignee: gmcharlt(a)gmail.com Summary: Cardnumber/accession number range when creating print batches in tools Severity: enhancement Classification: Unclassified OS: All Reporter: amit.gupta(a)osslabs.biz Hardware: All Status: NEW Version: rel_3_10 Component: Tools Product: Koha Give ability to generate print batches on the basis of barcode range. for example barcode range: 100001-100099 -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 8425] New: Duplicate barcodes generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '15

04 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8425 Priority: P5 - low Change sponsored?: --- Bug ID: 8425 Assignee: koha-bugs(a)lists.koha-community.org Summary: Duplicate barcodes generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on Severity: normal Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha Duplicate barcodes are generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on. The problem is that you can accidentally attach 3 items to an order, but only 1 will be saved to the database. When you go to receive your order, you can only receive 1 item as the other two were never made, since the barcode wasn't unique. In 3.8.0, a software error comes up which prevent any item creation, I believe, but master (3.9.x) doesn't throw any warnings or errors. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 9047] New: show hold info on self check out
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '15

04 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9047 Priority: P5 - low Change sponsored?: --- Bug ID: 9047 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: show hold info on self check out Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha In the self-check UI, it would be great if patrons could view holds and place in the queue (like they can when they log in to the opac). It would also be nice if it showed what holds were ready for pick up - like it does on the staff circ screen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9601] New: ccsr opac no results found ugly
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9601 Bug ID: 9601 Summary: ccsr opac no results found ugly Classification: Unclassified 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: nengard(a)gmail.com Created attachment 15280 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15280&action=edit no results In the CCSR template the no results page could use some work. See attached. The column on the left looks like it wants to appear and the text at the top is smooched together. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 10440] New: During receipting for any holds attached to items being receipted, to be identified during the receipting process.
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10440 Bug ID: 10440 Summary: During receipting for any holds attached to items being receipted, to be identified during the receipting process. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com During receipting for any holds attached to items being receipted, to be identified during the receipting process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 9844] New: Add a barcode queue to checkout / return
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '15

02 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9844 Bug ID: 9844 Summary: Add a barcode queue to checkout / return Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: viktor.sarge(a)regionhalland.se CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Background: Some testing on a 70Mbit+ connection to a remote Koha install indicates that the system is a bottleneck when it comes to issuing checkouts or returning items. If a staff user scan barcodes to fast for the system to keep up then barcodes are lost and books will not have been checked out or returned. Plack for the staff interface might solve a part of this problem, but adding a queue would be great. Suggestion: Add a queue-box with high visibility of items that are not yet processed when checking out or returning items. If a user scans items quicker than than the system can process items the box will fill up. The system should process the barcodes in the queue-box using AJAX-code so that the whole page will not have to reload for every barcode. Ending the session (by printing receipt for checkout etc.) should not be possible until the queue is empty. Messages that today appear once per page (like holds on a title for example) will have to be duplicated since a librarian could scan multiple codes until an item has been processed by the system. Implications on existing code: I think this might require us to rewrite some of circulation.pl and returns.pl to use Ajax, insert the queue-box and to display multiple messages at once. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5