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

[Bug 4255] Add item type to facet list
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '12

15 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4255 --- Comment #5 from Ian Walls <koha.sekjal(a)gmail.com> --- Created attachment 10296 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10296&action=edit [PASSED QA] Bug 4255 - Add item type to facet list This is for MARC 21 only. Made following changed: - In getFacets in C4/Koha.pm added item type facet for 952y and 942c - In getRecords in C4:Search.pm added code to get description of itemtype codes - facets.inc in both staff and opac to show item types related label in the facets block To test: Add records such that a certain itype (say BK) is present in both 942c and 952y in two DIFFERENT records. Run a search where both test records are present. Test to see if itype types are presented in the facets block (both OPAC and staff). Click on the itype (say BK), both the test records should appear in the refined results. This shows that the feature works for both 942c and 952y. Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> Signed-off-by: Ian Walls <koha.sekjal(a)gmail.com> QA Comment: fixed capitalization in template includes according to HTML4 coding guideline ("Item types" instead of "ItemTypes") -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 8182] New: Problem with overdue fine calculations after upgrade
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '12

15 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8182 Priority: P5 - low Change sponsored?: --- Bug ID: 8182 Assignee: gmcharlt(a)gmail.com Summary: Problem with overdue fine calculations after upgrade Severity: enhancement Classification: Unclassified OS: All Reporter: kyle.m.hall(a)gmail.com Hardware: All Status: NEW Version: master Component: Database Product: Koha Items that were overdue and still out as of 5/26 (date of Upgrade) were charged overdue fines as of 5/26. When the items DO come back, the overdue fines are calculated again from the due date to the date of checkin. Therefore the patron is being charged double overdue fines from the original date up to 5/26. This is caused by issues.date_due being changed to a datetime, with the hour/minute/secons time portion defaulting to 00:00:00. It should be 23::50::00 instead. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 8173] New: Have Full title (245) to always display in system
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '12

15 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8173 Priority: P5 - low Change sponsored?: --- Bug ID: 8173 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: Have Full title (245) to always display in system Severity: enhancement Classification: Unclassified OS: All Reporter: hbraum(a)nekls.org Hardware: All Status: NEW Version: rel_3_6 Component: Circulation Product: Koha The full MARC 245 title (245a, 245b, 245h, 245p, 245n fields) does not always display throughout the system. Three examples: in the patrons' checkout list and in the patron's holds list and in the checkout list in the patron's detail page. It is important for the full title information to display for multi-part video series or graphic novels, where there are names of parts and numbers of parts involved. That way a patron can tell which number/part they have of a work. I know this display issues also happens elsewhere in the system, too. Example 1: Display from the patron record details tab in the checkout area: http://screencast.com/t/rNcp7bDzvNh Actual 245 in MARC: http://screencast.com/t/oj9I5K1kDr Example 2: Display from the patron record checkout tab: http://screencast.com/t/eo0RTAxPBtNp Actual 245 in the MARC: http://screencast.com/t/weR4W0mSpJ -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 8165] New: due date of 00:00 instead of 23:59
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '12

15 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8165 Priority: P5 - low Change sponsored?: --- Bug ID: 8165 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: due date of 00:00 instead of 23:59 Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Circulation Product: Koha Created attachment 9843 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9843&action=edit Due dates at 00:00 All the items that are due today are showing due on 29th at 00:00 instead of 29th at 23:59. This means that overdue notices are being triggered early. On the 29th, the items are not technically overdue yet - the patron has until 23:59 to return them. It appears that all items, whether checked out today or checked out previously, are showing the default for the due date is 00:00 instead of 23:59. See attached image. This library is running 3.8.1. This may be related to the hourly loans development. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 6027] New: Delete biblios if deleting all their items in batch deletion
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '12

14 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6027 Bug #: 6027 Summary: Delete biblios if deleting all their items in batch deletion Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5992 This needs a lot of testing, I dont think it tests for any reserves on the biblio, before deleting. (Or serial subscriptions etc) -- 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 31

[Bug 2720] Fines that debar automatically, should undebar automatically when paid.
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '12

14 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 Kyle M Hall <kyle.m.hall(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle.m.hall(a)gmail.com --- Comment #2 from Kyle M Hall <kyle.m.hall(a)gmail.com> --- Right now, Koha debars a borrower when borrowers.debarred is set to a date ( which is the date the borrower's debarment will expire ). An optional comment is stored in borrowers.debarredocmment. Since there are numerous reasons for debarment, not just fines, but overdues, or a manual debarment, I imagine the best way to go about this is to add a table borrower_debarment which would have the fields borrowernumber, reason, date, comment. Reason would be an enumerated data type such as fines, overdues, and manual. When a borrowers fines go over the limit, a debarment for the borrower would go into this table. The same for overdues and manual debarment. If a borrower has a least one row in this table, they will be debarred. Paying fines will automatically remove a fines debarment, and returning overdue books will automatically remove an overdues debarment. This would require modifying all code that involves debarring, in particular C4::Overdues::CheckBorrowerDebarred, the borrower editing page, and the circulation pages. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 8189] New: checkout history link gives error
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '12

14 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8189 Priority: P5 - low Change sponsored?: --- Bug ID: 8189 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: checkout history link gives error Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Circulation Product: Koha If you search the catalog, then click on the title of an item, clicking the checkout history tab on the left side of the screen produces the following error message. Software error: The 'month' parameter ("0") to DateTime::new did not pass the 'an integer between 1 and 12' callback at /usr/lib/perl5/DateTime.pm line 194 DateTime::new(undef, 'hour', 00, 'minute', 00, 'month', 0, 'second', 0, ...) called at /usr/share/perl5/DateTime/Format/DateParse.pm line 58 DateTime::Format::DateParse::parse_datetime('DateTime::Format::DateParse', '0000-00-00 00:00:00', 'America/New_York') called at /home/koha/kohaclone/Koha/DateUtils.pm line 86 Koha::DateUtils::dt_from_string('0000-00-00 00:00:00', 'sql') called at /home/koha/kohaclone/Koha/DateUtils.pm line 160 Koha::DateUtils::format_sqldatetime('0000-00-00 00:00:00') called at /home/koha/kohaclone/catalogue/issuehistory.pl line 74 -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 7548] New: Missing arguments in the pagination of receptions
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '12

14 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7548 Bug #: 7548 Summary: Missing arguments in the pagination of receptions Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: pelletiermaxime(a)gmail.com QAContact: koha.sekjal(a)gmail.com In acquisitions, receive shipment and then enter a vendor invoice and click next. If you have more than 20 pending orders (you can change $resultsperpage = 20 unless ($resultsperpage); in the code to test) there will be a pagination at the bottom. The numbers don't have invoice and datereceived as arguments like the Next>>. Patch to follow. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 21

[Bug 8201] New: can't change receive date
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '12

14 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8201 Priority: P5 - low Change sponsored?: --- Bug ID: 8201 Assignee: henridamien(a)koha-fr.org Summary: can't change receive date Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha When receiving a shipment you can enter the invoice date. I entered a date in the past and it showed that date after hitting submit, but after I receive one item it changes the date back to today's date instead. The date needs to stay set to what the librarian sets - not change to anything else. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 7722] New: Insidious problem with searching
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '12

14 Jun '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7722 Priority: P5 - low Change sponsored?: --- Bug ID: 7722 Assignee: gmcharlt(a)gmail.com Summary: Insidious problem with searching QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: kyle.m.hall(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Searching Product: Koha I cannot find the root cause of this issue, but multiple libraries that I am aware of have problems searching on particular search terms ( and never the same terms at the same library ). The error they get when they trigger this problem is: Tag "" is not a valid tag. at /home/koha/kohaclone/C4/Biblio.pm line 1849 Something somewhere is adding empty keys to C4::Context->marcfromkohafield, I think it may have something to do with the analytics feature that was added. In the while loop for TransformKohaToMarc, there is a line next unless my $dtm = $db_to_marc->{''}->{$name}; I don't think it's working. If I dump $dtm, for each search, I see the dump twice. It looks like this: $VAR1 = [ '952', 'w' ]; $VAR1 = []; I think the second time, when it is empty is what's breaking this. The next never fails because even though it is empty, it is still a valid arrayref. The solution I have some up with is to skip over the elements where the arrayref is empty. -- You are receiving this mail because: You are watching all bug changes.

1 12