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

[Bug 5199] New: Renewals do not add branchcode to statistics table
by bugzilla-daemon＠bugs.koha-community.org 23 May '12

23 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5199 Summary: Renewals do not add branchcode to statistics table Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The AddRenewal() function of Circulation.pm is defined to take $branch as the third parameter, but most calls to this function, including OPAC renewal and Self Checkout, only take the first two, $borrowernumber and $itemnumber. This leaves the statistics table full of NULL values in the $branch field for renewal statistics. The $branch value passed should be the branch of the currently logged in user. This would be the current branch selected in the staff client, the patron's home branch in the OPAC, and the homebranch of the Self Checkout user for SCO. -- 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 19

[Bug 5150] New: Issuing should read Circulation
by bugzilla-daemon＠bugs.koha-community.org 23 May '12

23 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5150 Summary: Issuing should read Circulation Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: /cgi-bin/koha/admin/smart-rules.pl OS/Version: All Status: ASSIGNED Severity: trivial Priority: P5 Component: Templates AssignedTo: nengard(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Issuing has been changed to Circulation in most other places, so it should be consistent throughout. -- 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 5211] New: marking lost (long overdue) not charging fines
by bugzilla-daemon＠bugs.koha-community.org 23 May '12

23 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5211 Summary: marking lost (long overdue) not charging fines Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 It used to be that if you manually marked an item as Long Overdue (Lost) it would automatically charge the patron the replacement price for the item. This is not happening now unless you use the cron job to mark things long overdue and lost. It should happen in both instances. -- 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 10

[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 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

[Bug 5018] New: amount encumbered not showing on budgets
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '12

15 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5018 Summary: amount encumbered not showing on budgets 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 fund (cgi-bin/koha/admin/aqbudgets.pl?budget_period_id=3) not showing what is encumbered only what was spent - so it’s misleading to what is left in the budget - but it does show it on this page: cgi-bin/koha/acqui/acqui-home.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 2

[Bug 5647] New: Enhanced Notices are using name and not id
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '12

14 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5647 Summary: Enhanced Notices are using name and not id Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Notices AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 According to bug 5646 the messaging preferences can't be translated because the code queries the name and not the id. I am opening a new bug here because that bug has been "resolved" with a work around. Instead I think the code should be updated to check for the primary key (id) instead of the name. This is necessary for translations and so that we can make changes to those labels. >From Bug 5646 (reported by Katrin) If you tranlate the message names in the installer sql files your messages will stop working, because the code relies on those have a specific value. - advance_notices.pl - C4/Members/Messaging.pm - C4/Form/MessagingPreferences.pm ... In C4/Members/Messaging.pm I found following lines: 47 my $preferences = C4::Members::Messaging::GetMessagingPreferences( { borrowernumber => $borrower->{'borrowernumber'}, 48 message_name => 'DUE' } ); 50 my $preferences = C4::Members::Messaging::GetMessagingPreferences( { categorycode => 'LIBRARY', 51 message_name => 'DUE' } ); We don't have DUE as a message name in the en file. 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 2