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

[Bug 8606] New: Talking Tech broken by Bug 7001
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8606 Priority: P5 - low Change sponsored?: --- Bug ID: 8606 Assignee: koha-bugs(a)lists.koha-community.org Summary: Talking Tech broken by Bug 7001 Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Notices Product: Koha The patches for bug 7001 removed the parseletter subroutine from C4::Letters without updating the talking tech script to use the new alternative. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 7894] New: Broken detail page for first link on page 2 from search result page in OPAC
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7894 Priority: P5 - low Change sponsored?: --- Bug ID: 7894 Assignee: oleonard(a)myacpl.org Summary: Broken detail page for first link on page 2 from search result page in OPAC QA Contact: koha.sekjal(a)gmail.com Severity: blocker Classification: Unclassified OS: All Reporter: arslanone(a)gmail.com Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Hi, When you search the OPAC, clicking on the 1st result of page 2 always gives this error: ------------------------------------------- "Software error: Can't use string ("00800nam a22002537a 450000100050") as an ARRAY ref while "strict refs" in use at /usr/share/koha/lib/C4/Search.pm line 1493." ------------------------------------------- Screenshot: http://postimage.org/image/ouqivltox/ The error only happens when we search in the OPAC, go to page 2, and click on 1st record. Search a different term and, that will result in some different record on page 2 top, and clicking that record will give same error. Right click and copy the link of that record, and open it by directly pasting in another browser and the record will show properly. Meaning there is nothing wrong with the record itself. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 6151] New: IndependantBranches and HomeOrHoldingBranchReturn can prevent items from being checked in
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6151 Bug #: 6151 Summary: IndependantBranches and HomeOrHoldingBranchReturn can prevent items from being checked in Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: ASSIGNED Severity: major Priority: P5 Component: Circulation AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com If IndependantBranches is on, and an item is checked into a branch that is not it's current HomeOrHoldBranchReturn branch, a "Wrong Branch" message is given, and the return is denied. This is not always desirable behaviour. For example, some libraries may want an item owned by Branch A but issued from Branch B to be returnable to either A or B (the patron returning the material to A saves the library transit costs), or even to be returnable to Library C if the transit network is robust. More heinous a problem, if an item is issued from Library B, and HomeOrHoldingBranchReturn is set to Homebranch, the patron cannot return the item to Library B. And further, when AutomaticItemReturn is turned on and HomeOrHoldingBranchReturn is HoldingBranch, an item issued from Library B and returned to Library B will not trigger a transfer message to return it to Library A. So, with the two above, if HomeOrHoldingBranchReturn is considered the only adjustable variable (since changing IndependantBranches has many, many consequences, and AutomaticItemReturn is a library policy decision), neither setting will allow for desirable behaviour. -- 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 8428] New: can't save contracts
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8428 Priority: P5 - low Change sponsored?: --- Bug ID: 8428 Assignee: koha-bugs(a)lists.koha-community.org Summary: can't save contracts Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com URL: /cgi-bin/koha/admin/aqcontract.pl?op=add_form&booksell erid=1 Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha I'm trying to create a contract and no matter how many times I click the save button nothing happens. I get no errors, no saving, no confirmation, just nothing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 8598] New: borrower image and home library disappear on Files tab
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8598 Priority: P5 - low Change sponsored?: --- Bug ID: 8598 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: borrower image and home library disappear on Files tab Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com URL: /cgi-bin/koha/members/files.pl?borrowernumber=52 Hardware: All Status: NEW Version: master Component: Patrons Product: Koha Created attachment 11451 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=11451&action=edit patron on all other tabs When looking at patron files the patron's image and home library on the top left disappear. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 8761] New: Correct compile time warnings in C4::Circulation
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8761 Priority: P5 - low Change sponsored?: --- Bug ID: 8761 Assignee: gmcharlt(a)gmail.com Summary: Correct compile time warnings in C4::Circulation Severity: minor Classification: Unclassified OS: All Reporter: colin.campbell(a)ptfs-europe.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha A recent enhancement to C4::Circulation has introduced some ambiguous constructs which on current perls give compile time warnings with perl 5.16.0 or 5.16.1 (I've not tested with older) if you check compilation with perl -wc C4/Circulation.pm you get the following warnings Scalar value @values[$take] better written as $values[$take] at Circulation.pm line 985. Scalar value @alloweddate[0] better written as $alloweddate[0] at Circulation.pm line 991. Scalar value @alloweddate[1] better written as $alloweddate[1] at Circulation.pm line 993. Scalar value @alloweddate[2] better written as $alloweddate[2] at Circulation.pm line 993. Scalar value @alloweddate[2] better written as $alloweddate[2] at Circulation.pm line 994. Heres the doc from perlwarn (W syntax) You've used an array slice (indicated by @) to select a single element of an array. Generally it's better to ask for a scalar value (indicated by $). The difference is that $foo[&bar] always behaves like a scalar, both when assigning to it and when evaluating its argument, while @foo[&bar] behaves like a list when you assign to it, and provides a list context to its subscript, which can do weird things if you're expecting only one subscript. On the other hand, if you were actually hoping to treat the array element as a list, you need to look into how references work, because Perl will not magically convert between scalars and lists for you. See perlref. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 8395] New: order receive not sorting right
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8395 Priority: P5 - low Change sponsored?: --- Bug ID: 8395 Assignee: koha-bugs(a)lists.koha-community.org Summary: order receive not sorting right Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Acquisitions Product: Koha Created attachment 10722 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10722&action=edit not sorted See the attached image - when I click on the 'Summary' heading to sort things, they are in no order that I can figure out. They should be in alpha order by title since that's the first bit of data in that field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 8408] New: Odd OPAC message when OPAC Renewals are disabled and OPACFineNoRenewals is set to blank
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8408 Priority: P5 - low Change sponsored?: --- Bug ID: 8408 Assignee: oleonard(a)myacpl.org Summary: Odd OPAC message when OPAC Renewals are disabled and OPACFineNoRenewals is set to blank Severity: enhancement Classification: Unclassified OS: All Reporter: kyle.m.hall(a)gmail.com Hardware: All Status: NEW Version: master Component: OPAC Product: Koha If OpacRenewalAllowed is set to "Don't allow" and OPACFineNoRenewals is set to blank ( i.e. disabled ). A user who owes any fines, when logged in to the OPAC will receive the following message: Please note: You have more than 0.00 in fines. This is a rather odd message, and is not very sensible. The message should either be modified or removed altogether. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 4870] New: Damaged status does not prevent items from being selected for reserves
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4870 Summary: Damaged status does not prevent items from being selected for reserves Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Damaged status on items (952$4) seems to allow items to be selected for reserve. This happens both when the barcode is checked in and when the hold queue report is generated. Preferred behavior (open for discussion, of course) would be for damaged status to disallow reserves on items marked "Damaged," similar to items with a "Missing" status (though missing clears the status on checkin, we would NOT want that behavior for Damaged. It should be a manual status change). -- 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 16

[Bug 8486] New: Critical error in Koha::Calendar::days_between ?
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8486 Priority: P5 - low Change sponsored?: --- Bug ID: 8486 Assignee: colin.campbell(a)ptfs-europe.com Blocks: 7420, 8251 Summary: Critical error in Koha::Calendar::days_between ? Severity: blocker Classification: Unclassified OS: All Reporter: paul.poulain(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Architecture, internals, and plumbing Product: Koha My setup has syspref finesCalendar set "Use Calendar to skip all days the library is closed". I made the small following script: #!/usr/bin/perl use Koha::Calendar; use Koha::DateUtils; use 5.010; my $calendar = Koha::Calendar->new( branchcode => 'MAURES' ); say "Test 1=".$calendar->days_between(dt_from_string("2012-01-10") , dt_from_string("2012-05-05") )->in_units('days'); say "Test 2=".$calendar->days_between(dt_from_string("2012-05-05") , dt_from_string("2012-01-01") )->in_units('days'); The result I get is: ./test_calendar.pl DURATION : $VAR1 = bless( { 'seconds' => 0, 'minutes' => 0, 'end_of_month' => 'wrap', 'nanoseconds' => 0, 'days' => 26, 'months' => 3 }, 'DateTime::Duration' ); Test 1=26 DURATION : $VAR1 = bless( { 'seconds' => 0, 'minutes' => 0, 'end_of_month' => 'preserve', 'nanoseconds' => 0, 'days' => -4, 'months' => -4 }, 'DateTime::Duration' ); Test 2=-4 (the DURATION line comes from a warn I put in days_between Whatever the month, I always get the same result. Digging into documentation, I found this: $ perldoc DateTime::Duration · in_units( ... ) Returns the length of the duration in the units (any of those that can be passed to new) given as arguments. All lengths are integral, but may be negative. Smaller units are computed from what remains after taking away the larger units given, so for example: my $dur = DateTime::Duration->new( years => 1, months => 15 ); $dur->in_units( 'years' ); # 2 $dur->in_units( 'months' ); # 27 $dur->in_units( 'years', 'months' ); # (2, 3) $dur->in_units( 'weeks', 'days' ); # (0, 0) ! The last example demonstrates that there will not be any conversion between units which don't have a fixed conversion rate. The only conversions possible are: · years <=> months · weeks <=> days · hours <=> minutes · seconds <=> nanoseconds For the explanation of why this is the case, please see the How Datetime Math Works section of the DateTime.pm documentation CONCLUSION = the days_between() sub is doing a completely wrong calculation. I think we should to a date1-date2 to get a number of days, then remove all closed days. 2012-07-01 to 2012-07-15 is 14 (days) 2012-07-06 closed => 13 (days) 2012-07-07 closed => 12 (days) This problem is probably the real cause of bug 8251 and the trouble I get to test bug 7420 Colin, I've assigned this bug to you because you're Koha::Calendar initial author. Anyone is welcomed to confirm and provide a fix. What is really missing is a test plan. With a strong one, we would have detected the problem before -- You are receiving this mail because: You are watching all bug changes.

1 23