September 2015 - 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 2246] Label printing doesn't work with Unicode characters
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '15

10 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2246 Chris Nighswonger <cnighswonger(a)foundations.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11121 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 12471] New: Facility needed to create batch from patron list or query
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '15

10 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12471 Bug ID: 12471 Summary: Facility needed to create batch from patron list or query Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: koha(a)jsense.co.uk QA Contact: testopia(a)bugs.koha-community.org There is a very useful patron list creation facility to make batch management of patrons simpler. It would seem to make sense to connect this facility with the patron card printing tool in order to create batches. Sometimes we create cards for everyone in the library so it would also be good to create batches directly from queries but using lists would be the main requirement. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 14800] New: Adding Patrons to new Batch increments batchno instead of adding patron to list
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '15

10 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14800 Bug ID: 14800 Summary: Adding Patrons to new Batch increments batchno instead of adding patron to list Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: Heinrich.Hartl(a)email.de QA Contact: testopia(a)bugs.koha-community.org Created attachment 42471 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=42471&action=edit manage batch - after once new batch and add items adding three patrons I observed the following malfunction in 3.20: In pataron card creator after choosing new batch: By Add Item(s) I am offered a pop up window to search for patrons. In each row of all the patrons found for this search there is a button to add this patron to the (new) batch. After pressing this button the patron is really added to the new batch which now comprises just this one. If I want to add more patrons to the list and therefore continue e.g. with another search and pressing add for further patrons to be included in the batch the chosen patrons are not added to the just created batch but instead new batches are crated and I end with several new batches each one with exactly one patron in it! Apparently this is not so if i chose to edit an existing batch. Add item(s) and adding several patrons results correctly in extending the current batch. This is also my bypass for the problem. I created a batch with the first patron in it, returned to manage batches, chose again the just created batch for editing an could complement it with the other wanted patrons. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12085] New: Allow staff to place multiple reserves for the same patron
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '15

09 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12085 Bug ID: 12085 Summary: Allow staff to place multiple reserves for the same patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 27121 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=27121&action=edit Allow multiple reserves for the same patron This requires rather large changes to C4/Reserves.pm, because it didn't use the reserve_id to distinguish the reserves. -Remove all vestiges of reserveconstraints -table from the code. -Make Reserves use ID numbers as much as possible, instead of matching with patron number, bibnum, and date. -Allow the same patron reserve the same item multiple times, but only via staff client. -Adds syspref AllowMultipleHolds ---- I wrote this patch a while ago, and seeing all the other improvements in the area (for example bug 12079 and bug 11947), I decided to put this up here, perhaps it'll be of some use. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 13466] New: Changing language does not work
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '15

09 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13466 Bug ID: 13466 Summary: Changing language does not work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Changing language in the staff client results in a redirection error that firefox relates to blocked cookies (which is not the case). This has been a problem before, but I could not find the bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 14799] New: patron catalog security
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '15

09 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14799 Bug ID: 14799 Summary: patron catalog security 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: jesse(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a patron logs in to their account on the KOHA opac , then logs out, then uses the back button to go back, their account information is still available. This seems like a security issue. When a patron logs out, their information should not be still available for anyone to see by using the back button (or any other way). -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 14796] New: zebra returns error code 114
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '15

09 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14796 Bug ID: 14796 Summary: zebra returns error code 114 Change sponsored?: --- Product: Koha Version: 3.18 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: wwwretive(a)yahoo.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 42458 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=42458&action=edit koha-rebuild-zebra output Search did not work anymore with recently acquired items but it was OK for old ones; i updated koha from version 3.18.9 to version 3.18.10, but now the search doesn't work for any of the items. It doesn't work for a general search neither for a particular search (title, author, etc) The format of the database is unimarc. When i look at the zebrasrv logs it says zebrasrv(1) e0489cb5 [request] Search biblios ERROR 114 1 1+0 RPN @attrset Bib-1 @attr 1=1016 @attr 4=6 @attr 5=1 social I tried the yaz client directly, it says : # yaz-client -c /etc/koha/zebradb/ccl.properties unix:/var/run/koha/laretive/bibliosocket Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.004361 Z> base biblios Z> f social Sent searchRequest. Received SearchResponse. Search was a bloomin' failure. Number of hits: 0, setno 1 Result Set Status: none records returned: 0 Diagnostic message(s) from database: [114] Unsupported Use attribute -- v2 addinfo 'any' I did koha-rebuild-zebra but that didn't help (output is attached) Any help will be appreciated. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 14797] New: Cancelling orders with no alert to existing holds
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '15

09 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14797 Bug ID: 14797 Summary: Cancelling orders with no alert to existing holds Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When AcqCreateItem is set to create an item when placing an order, this allows holds to be placed on on-order items. When an order is then cancelled, there is no alert to existing holds. When the order is cancelled, there is still a link to the hold against the bib record but the Holds screen in the bib record states that you cannot place holds as no item exists. As a result, you cannot cancel the hold from this screen nor can library staff see the patron details to inform them. As a workaround, they can add a new temporary item to allow them to delete the hold but it would be good to have an alert appearing on screen at the point of cancelling the order (via the Delete Order link in the Basket) so that the link to the hold record could be broken first. Workflow to reproduce: - Set AcqCreateItem to 'placing an order'. - From the Acquisitions screen, select a vendor, create a new basket and add an order to this basket. - As the system preference is set to add the item, fill out all the relevant - item information as well as other acq info. - Once saved, create a hold for a patron - Confirm that hold is present and can be seen from the bib record - From the open basket (so reopen if already closed), select the 'Delete Order' link against the correct orderline. - Enter cancellation reason and click Yes. Order is then cancelled but there was no alert about the hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 13601] New: Get rid of DateTime::Format::DateParse
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '15

08 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13601 Bug ID: 13601 Summary: Get rid of DateTime::Format::DateParse 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 For a couple of reasons, dt_from_string should not use DateTime::Format::DateParse: 1/ It does not manage date < 1900 (certainly caused by l.47 of this module: $p{ year } = $year ? $year + 1900 : DateTime->now->year; 2/ It considers 31/01/2015 as a valid us date, which is not. -- You are receiving this mail because: You are watching all bug changes.

1 76