September 2011 - Koha-bugs - lists.koha-community.org

[Bug 4223] Too much serials info - design work needed
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '11

28 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4223 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Patch Status|Does not apply |Needs Signoff -- 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 0

[Bug 4223] Too much serials info - design work needed
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '11

28 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4223 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #2221|0 |1 is obsolete| | --- Comment #3 from Owen Leonard <oleonard(a)myacpl.org> 2011-09-28 14:01:16 UTC --- Created attachment 5625 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5625 Proposed fix This patch reimplements the changes suggested in the original patch. It puts each main section of the display into its own tab. -- 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 0

[Bug 2246] Label printing doesn't work with Unicode characters
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '11

28 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2246 --- Comment #13 from D Ruth Bavousett <ruth(a)bywatersolutions.com> 2011-09-28 12:51:13 UTC --- I tried making wajasu's edit to a system known to be having this problem--code updated as of last night at HEAD, and it did not resolve the problem for me--I got a "this PDF is broken and cannot be repaired" error. :( -- 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 0

[Bug 6673] New: Create Batch Label from Staged MARC Records fails after upgrade to 3.4.x
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '11

28 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6673 Bug #: 6673 Summary: Create Batch Label from Staged MARC Records fails after upgrade to 3.4.x Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: larry(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Several sites are reporting that after upgrading Koha 3.4.x, they are unable to run Create Batch Label, from the Staged MARC Records page. Error message is: "Error attempting to create label batch. Please ask your system administrator to check the log for more details." -- 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 16

[Bug 2246] Label printing doesn't work with Unicode characters
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '11

28 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2246 wajasu <matted-34813(a)mypacks.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matted-34813(a)mypacks.net --- Comment #12 from wajasu <matted-34813(a)mypacks.net> 2011-09-28 06:43:55 UTC --- Improvement With hopes of getting diacritics ( u dieresis and such) printing for my barcode labels, I dug into /home/koha344/koha/intranet/cgi-bin/labels/label-create-pdf.pl I found that if I set the utf8 flag off for the $line string, it would end up sending FC instead of C3BC in the PDF. So for the "standard PDF encodings that we currently allow (Helvitica, Courier, etc) the single byte maps to those common foreign characters just fine. It worked for me! Here is the "utf8::downgrade($line);" that I used from this section of code. I am running perl 5.12.1 (that I built), with the latest cpan modules pulled as of Sept 2011, and koha 3.4.4. (your wide character fix in PDF.pm helped). It seems to get through my latest version of PDF::Reuse, that I have installed. sub _print_text { my $label_text = shift; foreach my $text_line (@$label_text) { my $pdf_font = $pdf->Font($text_line->{'font'}); my $line = "BT /$pdf_font $text_line->{'font_size'} Tf $text_line->{'text_llx'} $text_line->{'text_lly'} Td ($text_line->{'line'}) Tj ET"; utf8::downgrade($line); # This forces the utf8 flag off so the single byte will pass thru for regular PDFEncoding etc. # (So now my basic diacritics in the standard character sets will not get double encoded. Yeah! # Note: This is not meant to deal with the case where we want to use unicode with TTF - truetype fonts. $pdf->Add($line); } } This bug is log overdue, and it might be possible for someone to test and patch it, since I might not be able to get it done before Oct 8th 2011 for the 3.6 release. Note: I didn't want to loose this info. I also tried this fix in my production 3.0.2 environment. I had to add the PDF.pm patch for wide chars, to get a PDF to be generated. Once I added the downgrade line in 3.0.2, my create-label-pdf.pl hung, with some recursion error and cpu at 100%. So I gave up on 3.0.2. The PDF:Reuse in that version might be the factor, or something else. I'm going to grab koha 3.4.5 and try the fix on that. We can't wait till next year for this, can we? I also coded it with a TTF truetype font, but was missing the description lines, so I didn't have time to figure out the drawing logic. We would need to add a way to select a font path, or upload one, and store it in the database. Also, this fix might be usable for other create-*-pdf.pl scripts (like patron cards). This is a partial fix if we need to support other languages. -- 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 0

[Bug 6871] New: Have a link to the schema page on the reports page
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '11

27 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6871 Bug #: 6871 Summary: Have a link to the schema page on the reports page Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Reports AssignedTo: gmcharlt(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org >From the staff client reports page, we should include a link to the schemaspy output at schema.koha-community.org to make it easier for people. -- 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 16

[Bug 6928] New: xsltns:items="http://www.koha.org/items" should be changed to xmlns:items="http://www.koha-community.org/items"
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '11

27 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6928 Bug #: 6928 Summary: xsltns:items="http://www.koha.org/items" should be changed to xmlns:items="http://www.koha-community.org/items" Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org for consistency with the current website, the xml namespaces in xslt should be updated from koha.org to koha-community.org. It is my understanding that the namespace itself is an arbitrary string - perhaps we can make it meaningful again? -- 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 2

[Bug 6609] New: Clean up guided reports dictionary entry process
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '11

27 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6609 Bug #: 6609 Summary: Clean up guided reports dictionary entry process Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/reports/dictionary.pl OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Reports AssignedTo: oleonard(a)myacpl.org ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org Some general interface cleanup tasks with the guided reports dictionary entry process: - Improving the breadcrumb links - Eliminating the tabs in favor of more descriptive <legend> labels - Clarifying some labels - Correcting form markup according to established patterns (Undertaken primarily because the tabs translated poorly when trying to re-implement them for Bug 5481, Replace YUI JS libraries with Jquery UI) -- 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 5

[Bug 3521] Items table in catalogue/detail.pl and cataloguing/additem.pl is sorted nonsensically
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '11

27 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3521 Paul Poulain <paul.poulain(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.poulain(a)biblibre.com Patch Status|Needs Signoff |Failed QA --- Comment #6 from Paul Poulain <paul.poulain(a)biblibre.com> 2011-09-27 15:33:18 UTC --- I was wondering if the best order would not be homebranch, location, callnumber, enumchron, copynumber, dateaccessioned Aren't there cases where it's usefull to have location & callnumber ? Usually, all issues of a given biblio are all stored at the same location/callnumber, so that won't make a difference, but for non serials, there would be. I agree with Nicole the results are not properly sorted though. -- 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 0

[Bug 4841] New: Advanced search returns 0 results if the itemtype have no items
by bugzilla-daemon＠bugs.koha-community.org 26 Sep '11

26 Sep '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4841 Summary: Advanced search returns 0 results if the itemtype have no items Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: altiraboschi(a)yahoo.com.ar QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When you specify the item type of that you’re searching, advanced search seeks on the subfield 952$y. So, if you do not have items, the search returns 0 results. You can modify two templates in such a way that the criteria of search were the subfield 942$c: /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/catalogue/advsearch.tmpl /usr/share/koha/opac/htdocs/opac-tmpl/prog/en/modules/opac-advsearch.tmpl In these files you should change mc- with itemtype -- 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 6