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

[Bug 5749] New: The display of borrower adresses composed of streetnumber, streettype and address is broken
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5749 Summary: The display of borrower adresses composed of streetnumber, streettype and address is broken Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5575 Estimated Hours: 0.0 This manifests in the staff client -- 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 26

[Bug 5657] New: biblio records update fails when updating multiple authorities linked with the same biblio
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5657 Summary: biblio records update fails when updating multiple authorities linked with the same biblio Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: januszop(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Created attachment 3022 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3022 Proposed patch There is a following issue in authority support, when updating multiple authorities and then updating biblio records in batch (in Zebra mode). If both happens: 1) two authorities linked with the same bibliographic record are updated; 2) and then between two subsequent calls of the merge function (i.e. by merge_authority.pl script) the zebra database will not be updated, then after the second call of the merge function the field controlled by the first authority will return to its original state. This is because in the merge functions (in Zebra mode) the bibliographic records to be updated are collected from zebra database and not from sql database, which contains the fresh updated version of records. Imagine the following scenario: there are two authors of a work described by record R, say A and B. A and B have their authority records. We are updating both authority records and the authors become now A1 and B1 (in authorities). We have Zebra indexes and dontmerge syspref set to 1. Now we run merge_authority.pl script in batch mode. After the first run of the while loop author A in R becomes A1 (and R becomes R1) and the updated record is stored (by ModBiblio called from merge) only in sql database. So far so good. But then, in the second run, merge functions selects records for update from zebra database so, if zebra queue processing was not fast enough or was switched off at the moment, what will be updated now is R from zebra database (and not R1 from sql database). And therefore after the second run we get R2, where the second author is B1, but first is still A. Attached is a simple workaround. Comments are welcome. -- 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 5482] New: Translation problem in guided reports - Item field names
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5482 Summary: Translation problem in guided reports - Item field names Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: I18N/L10N AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The whole guided reports module has a lot of translation issues. One problem are the non-translatable item field names. The field names are also not matching descriptions used in other modules, one example is: Module: Catalog Item cancelled = Item withdrawn Example: Catalog koha-tmpl / intranet-tmpl / prog / en / columns.def The file seems not translatable, outdated and contains fields not existing in our database. The English labels don't match the normal Koha descriptions: Not existing: items.binding items.spystatus items.spydescr items.spycopydata Descriptions: Item cancelled = Item withdrawn ... I can fix the fields and labels - but this will not fix the translation problem. Is there a way we can make them translatable? -- 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 17

[Bug 4976] New: Status of item returned with process_koc.pl is empty in Intranet
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4976 Summary: Status of item returned with process_koc.pl is empty in Intranet Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 I have made several returns with the offline client, then uploaded and processed the resulting file with offline_circ/process_koc.pl. When I view the detail for a returned record (e.g. /cgi-bin/koha/catalogue/detail.pl?biblionumber=X) the status of the returned item is empty (all the other items have statuses like "Available" or "On lon to...") When I view the same record in the OPAC (/cgi-bin/koha/opac-detail.pl?biblionumber=X) all the items have statuses. -- 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 8

[Bug 6372] New: Batch progress bar does not check for 0 size jobs; should be in separate js too
by bugzilla-daemon＠bugs.koha-community.org 08 May '12

08 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6372 Bug #: 6372 Summary: Batch progress bar does not check for 0 size jobs; should be in separate js too Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Batch progress bar does not check for 0 size jobs, and divides by 0, with unpredictable effects. Also, putting progress bar javascript inline makes it impossible to debug. It is possible that this change will improve situation with some bugs reported against background jobs that use progress bar. -- 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 15

[Bug 6829] New: Remove two warnings for opac-MARCdetail
by bugzilla-daemon＠bugs.koha-community.org 03 May '12

03 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6829 Bug #: 6829 Summary: Remove two warnings for opac-MARCdetail Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org Remove this warning by adding a check: [Thu Sep 01 14:20:18 2011] [error] [client 192.87.126.61] [Thu Sep 1 14:20:18 2011] opac-MARCdetail.pl: Use of uninitialized value in string ne at /usr/share/koha/testclone/opac/opac-MARCdetail.pl line 145., referer: http://libdevelop.rijksmuseum.nl:8008/cgi-bin/koha/opac-detail.pl?biblionum… And this warning: [Mon Aug 29 13:58:02 2011] [error] [client 66.249.72.86] [Mon Aug 29 13:58:02 2011] opac-MARCdetail.pl: Use of uninitialized value in string comparison (cmp) at /usr/share/koha/prodclone/opac/opac-MARCdetail.pl line 238. This warning is still generated in 3.3.0.12, but could be resolved in 3.5 with the removing of 952 from marcxml. The check does not hurt however. -- 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 25

[Bug 6916] New: Selecting the acq date of an item should take you to the invoice page for it
by bugzilla-daemon＠bugs.koha-community.org 01 May '12

01 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6916 Bug #: 6916 Summary: Selecting the acq date of an item should take you to the invoice page for it Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Currently it takes you to the basket rather than the invoice, making it harder to see those 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 28

[Bug 6931] New: hardcoded insert incompatible with UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '12

30 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6931 Bug #: 6931 Summary: hardcoded insert incompatible with UNIMARC Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org In updatedatabase, the $DBversion = "3.03.00.015"; contains : my $sth = $dbh->prepare("INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, `tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, `hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES ( ?, '9', '9 (RLIN)', '9 (RLIN)', 0, 0, '', 6, '', '', '', 0, -5, '', '', '', NULL)"); $sth->execute('648'); $sth->execute('654'); $sth->execute('655'); $sth->execute('656'); $sth->execute('657'); $sth->execute('658'); $sth->execute('662'); =>> it's marcflavour independant and will result in some pain in UNIMARC ! (648...662 should not exist in standard UNIMARC so, 1- dead data will be added and 2-if a library uses those fields for local use, that will break a lot of things (ie : the 6xx are used for authorities, the $9 for authid, so, I don't imagine what the result will be !) A simple if syspref("marcflavour") eq "marc21" before the insert should fix the bug -- 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 8

[Bug 7263] New: Determine maximum length of some fields or subfields when cataloguing
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '12

27 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7263 Bug #: 7263 Summary: Determine maximum length of some fields or subfields when cataloguing Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: juan.sieira(a)xercode.es QAContact: ian.walls(a)bywatersolutions.com Determine maximum length of some fields or subfields when cataloguing a biblio or an item. Some libraries need to specify the maximum number of characters you can have a field or subfield, whether cataloguing a biblio or an item. For default it will be 9999 max length. -- 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 34

[Bug 6787] New: NORMARC needs a Fast Add framework
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '12

27 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6787 Bug #: 6787 Summary: NORMARC needs a Fast Add framework Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com ...and it's just about to get it! -- 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 9