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

[Bug 6205] New: doc-head-open.inc not found.
by bugzilla-daemon＠bugs.koha-community.org 23 May '12

23 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6205 Bug #: 6205 Summary: doc-head-open.inc not found. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P5 Component: Installation and upgrade (web-based installer) AssignedTo: henridamien(a)koha-fr.org ReportedBy: rudyhinojosa2007(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Software error: Template process failed: file error - doc-head-open.inc: not found at /usr/share/koha/lib/C4/Templates.pm line 119. I'm running the latest from the git repository as of 4-18-2011. On Ubuntu 10.10 Server. -- 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 20

[Bug 5785] New: Holds should catch new acquisitions
by bugzilla-daemon＠bugs.koha-community.org 23 May '12

23 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5785 Bug #: 5785 Summary: Holds should catch new acquisitions Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com When a new item is added to a bib with bib-level holds, the holds system is not triggered by the new item, even though it should be (if the item type permits holds according to the circulation rules). -- 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 4819] New: Add ID tags to certain areas of OPAC so jquery can be used to hide them
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4819 Summary: Add ID tags to certain areas of OPAC so jquery can be used to hide them Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 I've gotten requests to hide various parts of the OPAC screen that don't presently have tags, so it's been hard to do it with jquery. This patch adds tags to three places. * The OPAC search strategy -- some sites don't want to see the actual strategy used to display (e.g., “ mc-itype:BK or mc-itype:CR”), just the count. I added a span surrounding that part of the line, and put the word Search in front. Now the line reads Search “ mc-itype:BK or mc-itype:CR” returned 2235 results. If this jquery is used: $("#strategy").remove(); The line reads Search returned 2235 results. * The OPAC record display -- I've had a couple of requests to turn off the Notes tab. I added a span to it, so that using this jquery: $("#holdingnotes").remove(); hides that tab. * The OPAC patron account messaging tab -- Enhanced Messaging Preferences syspref has to be on for hold notices etc. to get sent out, but if that syspref is on, the Messaging tab shows in the OPAC patron account. Some sites do not want to allow patrons to change the settings. I added a span to that tab, so that using this jquery: $("#showmsgtab").remove(); hides the messaging 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 17

[Bug 6125] New: Plugin for date acquired does not work on ACQ framework
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6125 Bug #: 6125 Summary: Plugin for date acquired does not work on ACQ framework Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All URL: /cgi-bin/koha/acqui/neworderempty.pl?booksellerid=1&ba sketno=2# OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org It does not work because the plugin dateaccessioned is wrong. dateaccessioned relies on a javascript sub (set_to_today) that is defined in additem.pl. For acquisition (and serials), the set_to_today is not defined. -- 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 13

[Bug 5841] New: routing slip not displaying publication date
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5841 Bug #: 5841 Summary: routing slip not displaying publication date Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: reed(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org If printed from the 'edit routing list' page the routing slip shows the publication date. If printed from the 'print list' page, no publication date is shown. Patch to be provided add this in koha-tmpl/intranet-tmpl/prog/en/modules/serials/serials-collection.tmpl -- 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 24

[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 5017] New: can enter multiple funds with the same code
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '12

15 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5017 Summary: can enter multiple funds with the same code Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2375 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2375 codes Code is not unique when adding funds - you can enter multiples with the same code - so why have a code? -- 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 4