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

[Bug 4990] New: reintegrate overdues email in overdue list
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '15

16 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4990 Summary: reintegrate overdues email in overdue list Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nahuel.angelinetti(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 In 2.2 that email links worked. Now it doesn't, It should be re-implemented. It must be attached to a specific letter. -- 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 14

[Bug 10478] New: Do we need a sequential number generator?
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '15

14 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10478 Bug ID: 10478 Summary: Do we need a sequential number generator? Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl Copy and past from report 9921: --- Comment #15 from Galen Charlton <gmcharlt(a)gmail.com> --- (In reply to comment #14) > 3) I feel that incrementalControlNumber is not (really) a pref. I can > imagine more cases where we might need a sequential number. Would it be > interesting to move it perhaps to Tools in a more general context such as a > sequence number engine with its own table (id, keyname, seqnumber, date)? > There are more fields like callnumber (with plugins) that could use such an > approach.. > This does again not block your patch, but we could trigger the discussion on > a more general solution. This idea (creating a sequence engine) is worth elevating to a new enhancement bug. There's been some chatter on #koha the past few days about this in the context of improving how sequential patron cardnumbers are assigned. [END-OF-QUOTE] Note: Since this bug is not yet in assigned status, you are welcome to write some code :) It would probably be interesting too to add another column subkey or something that allows you to have sequence number for the combination key, subkey. You could e.g. have numbers then for 'shelf', '1 A' and 'shelf','2 C', etc. But this idea could have many more applications. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 10784] New: SMS-related code needs improvements
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '15

14 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10784 Bug ID: 10784 Summary: SMS-related code needs improvements Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)enger.priv.no QA Contact: testopia(a)bugs.koha-community.org Some more or less random findings: sms/sms_listen.pl has hardcoded strings in it, in Turkish (according to Google translate): http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=sms/sms_listen.pl… This comment from an earlier commit sounds ominous: "SMS - widespread cleanup and moving code away from Cyprus/Turkey-specific implementation. Much more needed." http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=9c8a1e29f8f2589… To bring this in line with other functionality in Koha it would probably be a good idea to make the notices editable, in the same way that other notices are. C4::SMS references two sysprefs, SMSSendUsername and SMSSendPassword, but when I search for these in 3.12.x and current master I get no results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 11390] New: DBIx::Class schema deployment script
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '15

14 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11390 Bug ID: 11390 Summary: DBIx::Class schema deployment script 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: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 7365 DBIx::Class has the ability to load a scheme defined by a set of DBIC schema classes into an empty database. We can use this to gain the ability to use a single script to deploy to either MySQL or PostgreSQL and set the stage for using DBIx::Class::Schema::Versioned to manage updates. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 5837] New: Change installer to use DBIx::Class::Schema::Versioned instead of updatedatabase.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '15

14 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5837 Bug #: 5837 Summary: Change installer to use DBIx::Class::Schema::Versioned instead of updatedatabase.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org In order to move us one step closer to database independence we should move to using a db independent schema. DBIx::Class::Schema gives us this. If we use DBIx::Class::Schema::Versioned we can do away with both kohastructure.sql and updatedatabase.pl -- 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 12

[Bug 7241] New: circulation action logs record biblionumber instead of item number
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '15

11 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7241 Bug #: 7241 Summary: circulation action logs record biblionumber instead of item number Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 - low Component: Transaction logs AssignedTo: paul.poulain(a)biblibre.com ReportedBy: ago(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com Issue log and and circulation logs are incorrectly recording biblionumber instead of item number, creating incorrect logs. -- 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 72

[Bug 9083] New: <<items.content>> in checkin/checkout notices does nothing
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '15

10 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9083 Priority: P5 - low Change sponsored?: --- Bug ID: 9083 Assignee: koha-bugs(a)lists.koha-community.org Summary: <<items.content>> in checkin/checkout notices does nothing Severity: minor Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: Notices Product: Koha As I understand it, the checkout and checkin notices use 'repetition markers' to generate a list of item/title information to display in the notice. The list of fields in the notice editor includes <<items.content>> as an option. If this is not supported it should be removed. For testing I used following paragraph in my notice templates: ---- BIBLIO/BIBLIOITEMS title <<biblio.title>> frameworkcode <<biblio.frameworkcode>> author <<biblio.author>> biblionumber <<biblioitems.biblionumber>> itemtype <<biblioitems.itemtype>> isbn <<biblioitems.isbn>> issn <<biblioitems.issn>> publishercode <<biblioitems.publishercode>> editionstatement <<biblioitems.editionstatement>> editionresponsibility <<biblioitems.editionresponsibility>> pages <<biblioitems.pages>> notes <<biblioitems.notes>> url <<biblioitems.url>> ITEMSCONTENT <<items.content>> ITEMS date due <<old_issues.date_due>> branchcode <<old_issues.branchcode>> returndate <<old_issues.returndate>> issuedate <<old_issues.issuedate>> ---- No information was output between ITEMSCONTENT and ITEMS. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 11121] New: Patron Card Creator batch export cannot handle special characters (usually)
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '15

10 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11121 Bug ID: 11121 Summary: Patron Card Creator batch export cannot handle special characters (usually) Change sponsored?: --- Product: Koha Version: 3.12 Hardware: PC OS: Linux Status: NEW Severity: trivial Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: vincent_muyo(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org Exporting a batch with special characters ( e g é, å, ä, ö) for patron posts <firstname> and <surname> will cause them to be corrupted in the exported pdf - é becomes Ã©, å becomes Ä¥ and ö becomes Ã¶, for example. However, this doesn't always happen - _usually_ the first page comes out correctly (but not with things already incorrect). Everything (apache2, MySQL, linux locale) is set to UTF-8, and label creator works flawlessly with these symbols. Going off an installation of the 3.12 liveDVD 3.12 (http://sourceforge.net/projects/kohalivedvd/) in Xubuntu. Guessing the exporter uses a different standard, e g ANSI, which corrupts the text - but this is pure guesswork. :) Extra information about the setup: Template is for an A4 page, SI Centimeters, 29.7x21. Cards 7.7x4.8, Margins 2x2. 2 columns, 4 rows, gaps 0.5cm each. Layout is layouted for front with guidebox on. It uses postscript points. Text fields Field 1 houses: the bug-related information <firstname> <surname>, font Helvetica size 12, alignment center, X: 20 Y: 100. Barcode number is printed, Code 39 (generated automatically in provided Katipo style), X:20, Y: 40 Koha 3.12.05.000 OS version ('uname -a'): Linux ubuntu 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 13:43:27 UTC 2013 i686 athlon i386 GNU/Linux Perl interpreter: /usr/bin/perl Perl version: 5.014002 Perl @INC: /usr/share/koha/lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . MySQL version: mysql Ver 14.14 Distrib 5.5.32, for debian-linux-gnu (i686) using readline 6.2 Apache version: Server version: Apache/2.2.22 (Ubuntu) Zebra version: Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. SHA1 ID: 419ad759807269fdfa379799a051ed3a551c6541 Using ICU Running this in a virtual machine, VirtualBox. -- You are receiving this mail because: You are watching all bug changes.

1 4

[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 11213] New: GetItemsInfo() called twice
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '15

08 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11213 Bug ID: 11213 Summary: GetItemsInfo() called twice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: srdjan(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Details pages opac/opac-detail.pl and catalogue/detail.pl call GetItemsInfo() on their own after it being called from XSLTParse4Display() (if OPACXSLTDetailsDisplay syspref and/or XSLTDetailsDisplay are set). That imposes severe performance penalty for biblio records with large number of items. The right way would be to pass the list to XSLTParse4Display(), however that interface is very complex as is. An alternative is to return the list from XSLTParse4Display(), which is not elegant at all. If no one cries foul in the next 24 hours, I'll proceed with changing the interface. -- You are receiving this mail because: You are watching all bug changes.

1 85