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

[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 6369] New: Formatting problems on some items when printing an order form (PDF).
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '12

20 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6369 Bug #: 6369 Summary: Formatting problems on some items when printing an order form (PDF). Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: fcapovilla(a)live.ca QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4174 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4174 Correct a formatting problem in the pdf generation of basketgroup.pl In /acqui/basketgroup.pl : When printing an order form for a basketgroup, some items appeared incorrectly in the resulting pdf file. The formatting problem happens if $ord->{itemtype} has a value, but $bib->{itemtype} does not. Patch attached to correct this problem. -- 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 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 6211] New: SubscriptionHistory doesn't have default value set
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '12

15 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6211 Bug #: 6211 Summary: SubscriptionHistory doesn't have default value set Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org I'm not sure how else to title this bug. When you do a fresh install your SubscriptionHistory preference says it's set to 'full' but when you view the OPAC it's not the full history it's the brief. When you change it to brief it doesn't change the display - but if you change it back to full after changing to brief you finally get the full history. I think this is because the value showing by default is just there because of the order it appears in the list and not because the value is actually set in the database. -- 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 7

[Bug 5798] New: SubscriptionHistory default not applied
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '12

15 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5798 Bug #: 5798 Summary: SubscriptionHistory default not applied Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org On a new install SubscriptionHistory is set to full history, but the default display is not full. To get it to show full you have to set it to 'a summary' and then save and then set it back to 'full' -- 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 1

[Bug 6339] New: ExtendedPatronAttributes to allow for a DatePicker (JS Calendar) style field
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '12

14 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6339 Bug #: 6339 Summary: ExtendedPatronAttributes to allow for a DatePicker (JS Calendar) style field Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: indradg(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 4111 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4111 Screenshot of the desired functionality ExtendedPatronAttributes fields presently allow for Repeatable, Searchable, Unique ID, text type input box as well as auth_val driven select lists. It would be nice to have a date picker calendar pop-up facility and ValidateDate() function for the field as its parameters Possibly lib/C4/Members/AttributeTypes.pm, intranet/cgi-bin/admin/patron-attr-types.pl, intranet/htdocs/intranet-tmpl/prog/en/modules/admin/patron-attr-types.tmpl would require some functional changes I've attached a screenshot of the feature. Right now I'm doing it with an ugly jquery hack via intranetuserjs (http://pastebin.com/BPQw43tY) -- 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 1

[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

[Bug 5854] New: lists should print call numbers
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '12

14 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5854 Bug #: 5854 Summary: lists should print call numbers Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Virtual Shelves AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org In the OPAC when you print a list it includes the call number, but in the staff client it's missing this important piece of information, both in the printed version and on the screen. -- 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 1