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

[Bug 5801] New: C4::Circulation::_GetCircControlBranch doesn't work in opac-reserve.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '12

30 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5801 Bug #: 5801 Summary: C4::Circulation::_GetCircControlBranch doesn't work in opac-reserve.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: fridolyn.somers(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org In opac-reserve.pl : my $branch = C4::Circulation::_GetCircControlBranch($itemLoopIter, $borr); This doesn't work because _GetCircControlBranch looks for homebranch nor holdingbranch. But $itemLoopIter doesn't contain those. I propose : my $branch = C4::Circulation::_GetCircControlBranch( $itemInfo , $borr); -- 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 23

[Bug 7687] New: Remove problematic CSS gradient declarations targeting Internet Explorer
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '12

30 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7687 Priority: P5 - low Change sponsored?: --- Bug ID: 7687 Assignee: oleonard(a)myacpl.org Summary: Remove problematic CSS gradient declarations targeting Internet Explorer QA Contact: koha.sekjal(a)gmail.com Severity: minor Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: ASSIGNED Version: master Component: Browser compatibility Product: Koha Compatibility of CSS gradients in Internet Explorer is looking worse than I expected. I propose to remove the gradient from these elements in favor of a solid background: - Cart and Lists buttons : Applying a background gradient to these elements causes the background to "bleed" out of the rounded corners in IE9 creating an ugly halo. - Lists menu and patron menu items : These elements use gradients which in standards-compliant browsers accept several "steps" (color 1 blended with color 2 blended with color 3). IE only understands two colors. Better to have a solid background than the inferior fallback IE ends up with. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 9031] New: Overdue items crossing DST boundary throw invalid local time exception
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '12

30 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9031 Priority: P5 - low Change sponsored?: --- Bug ID: 9031 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Overdue items crossing DST boundary throw invalid local time exception Severity: minor Classification: Unclassified OS: All Reporter: robsongalluci(a)hotmail.com Hardware: All Status: NEW Version: 3.8 Component: Circulation Product: Koha When checking in an overdue item with a DST boundary between original due date and actual check in date, we get the invalid local time error. The issue happens with places that set DST by removing the hour between 0:00 and 0:59, as you can see here (http://www.nntp.perl.org/group/perl.datetime/2012/06/msg7854.html) not with every DST boundary crossing. The problem seems to be in the days_between and hours_between subroutines at Koha::Calendar. I've made a quick fix converting the dates to UTC before the calculation of the number of days, but I don't know if it deserves to be a patch. Ideally, all internal date handling should be done in UTC, using local timezones for input and output only, as DateTime page recommends: > - use UTC for all calculations > > If you do care about time zones (particularly DST) or leap seconds, try to use > non-UTC time zones for presentation and user input only. Convert to UTC > immediately and convert back to the local time zone for presentation https://metacpan.org/module/DateTime#Making-Things-Simple -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 9137] New: Focus when editing/adding new itemtypes/authorised values
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9137 Bug ID: 9137 Summary: Focus when editing/adding new itemtypes/authorised values Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de When you add a new authorised value or a new item type the focus is in no field on the page. I think it would be nice if you could start writing directly into the first field of the form after clicking the 'new ...' button. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 9106] New: Filtering list of uncertain price list by owner empties order information
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9106 Bug ID: 9106 Summary: Filtering list of uncertain price list by owner empties order information Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/acqui/uncertainprice.pl OS: All Status: NEW Severity: critical Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org On the list of uncertain prices there is an option to show orders by "me" or "Everyone." Submitting this form appears to do nothing because the form action clears quantity and pricing information from the orders. When the page refreshes there are no results because the "uncertain" flag has been cleared along with other order info from *all* orders which have uncertain prices. In the template, the filter form includes the op=validate field which is the parameter that tells the script to perform the ModOrder operation. Removing that form field should correct the problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 8614] New: Icon for scores on OPAC detail page broken
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8614 Priority: P5 - low Change sponsored?: --- Bug ID: 8614 Assignee: oleonard(a)myacpl.org Summary: Icon for scores on OPAC detail page broken Severity: enhancement Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Created attachment 11520 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=11520&action=edit screenshot The icon for scores on the OPAC detail page is not displaying correctly, instead following text is shown: Type: materialTypeLabelScore In other cases the score icon shows up on the result list, but on the detail page the article icon or the book is shown. It seems that different conditions are used to determine which icon to display on both pages. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 9173] New: manual_inv description confusing
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9173 Bug ID: 9173 Summary: manual_inv description confusing Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When adding a manual_inv authorized value the description is used for a monetary amount - this is confusing to most people who are used to using the description for ... well ... a description. Either the label when adding a manual invoice value should be changed to 'amount' or we need another field in the authorized value table for default values of some sort. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 3928] Expected Date v. Received Date
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3928 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Nicole C. Engard <nengard(a)gmail.com> --- I guess no one else has complained, so we can close it. Nicole -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 9170] New: deleting a patron with holds leaves orphaned holds
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9170 Bug ID: 9170 Summary: deleting a patron with holds leaves orphaned holds Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is not based in any code evidence ... it's just a guess of mine. I'm finding a lot of lines in the reserves table where there is no reservedate and no borrowernumber, but the found is still NULL. I'm thinking that when the patron is deleted their holds aren't moved to the old_reserves table or deleted, just their borrowernumber is being NULLed out. If this is the case, I think that the holds should be removed from the reserves table which should be the place for all current holds are stored. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 5753] New: Allow adults to be added to an organisation
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '12

29 Nov '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5753 Summary: Allow adults to be added to an organisation Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement 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 -- 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