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

[Bug 13817] New: Edit links on course items may point to the wrong course!
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13817 Bug ID: 13817 Summary: Edit links on course items may point to the wrong course! Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If items are assigned to multiple courses, the "edit" links for a course item may pass the wrong course id. This is really a cosmetic issue. It appears that in Template Toolkit, if you reuse an existing variable name in a foreach loop, it will not create a new temporary variable but will instead re-use the existing variable leaving assigned at the end to the last assignment, just as it would in Perl code. This is not a problem when all items are assigned to one and only one course, but can cause issues when we loop through the other courses an item may be on. This is solved easily by renaming the variable used in the foreach loop to another unused name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 14046] New: CheckIfIssuedToPatron fails if biblionumber != biblioitemnumber
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14046 Bug ID: 14046 Summary: CheckIfIssuedToPatron fails if biblionumber != biblioitemnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If for some reason biblionumber!=biblioitemnumber (it happens with test DB's) CheckIfIssuedToPatron fails. It's logic should be rewritten. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 14182] New: Suspended holds should show in separate list
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14182 Bug ID: 14182 Summary: Suspended holds should show in separate list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be helpful if suspended holds were moved to a separate suspended hold list below the active holds list, or on a separate tab, when reviewing holds on a bib record. They tend to blend together and staff don't always discern what is active and what is suspended. Christopher -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 12949] New: changing child to adult doesn't remove link to guarantor
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12949 Bug ID: 12949 Summary: changing child to adult doesn't remove link to guarantor Change sponsored?: --- Product: Koha Version: 3.16 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 QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. create an adult 2. add a child to said adult 3. edit child and change them to adult 4. see that link to guarantor is gone on child 5. search for guarantor (original adult) 6. see that there is still a guarantee there even though he/she is an adult now -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 10941] New: MARC21 documentation links while adding an authority
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10941 Bug ID: 10941 Summary: MARC21 documentation links while adding an authority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: tomascohen(a)gmail.com Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org While adding authorities (authorities.pl), we don't have the "?" now available on cataloging frameworks. A similar strategy might be used. Related bugs: #10940, #5546. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 2889] templates should not use [% IF ( loop.odd ) %]
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2889 Indranil Das Gupta <indradg(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |indradg(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3758] Automatic Exchange Rates
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3758 Indranil Das Gupta <indradg(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |indradg(a)gmail.com --- Comment #3 from Indranil Das Gupta <indradg(a)gmail.com> --- http://treasury.un.org/operationalrates/UNOperationalRatesRSS.xml seems to be a possible useful source. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 10113] New: Currency and cost calculation problem in acquisition
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10113 Bug ID: 10113 Summary: Currency and cost calculation problem in acquisition Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: shalomchong(a)segi.edu.my Created attachment 17667 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=17667&action=edit Set active currency in order page, total become "NaN" I have "NaN" value in my replacement cost, budgeted cost and total when I change the currency in order page to my active currency. I've set the same active currency for admin/currency & exchange rate and vendor, the basket page also displayed the active currency. but the default currency in my order page was other currency, the calculation is correct for this non-active currency, but the value for replacement cost, budgeted cost and total become "NaN" when I change the currency to my active currency. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 11939] New: Sample of currencies with a working active value
by bugzilla-daemon＠bugs.koha-community.org 11 May '15

11 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11939 Bug ID: 11939 Summary: Sample of currencies with a working active value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: z.tajoli(a)cineca.it QA Contact: testopia(a)bugs.koha-community.org In default english setup currencies are in mysql/en/optional/parameters.sql file. The default is set to USA dollar because its value is '1' but now this setup is not enough. Now is better to add also values in 'active' column. I insert 'active' (value '1') for USA dollar, 'not active' (value '0') for others. The description in mysql/en/optional/parameters.txt file is no more correct, so I correct it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 13135] New: cancel_expired_holds.pl/CancelExpiredReserves() logging improvements to catch evasive bugs in production.
by bugzilla-daemon＠bugs.koha-community.org 09 May '15

09 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13135 Bug ID: 13135 Summary: cancel_expired_holds.pl/CancelExpiredReserves() logging improvements to catch evasive bugs in production. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have issues with the Calendar giving bad expiration dates for waiting holds. So far unable to isolate the bug, which appears to appear only in prodcution. This logging improvement gives a lot more information about the cronjob internals in varying levels. (L1) Logs expired holds which have expirationdate overdue. (L1) Logs holds waiting too long, those that did get cancelled and (L2) those that didn't. (L3) Logs the used Calendar-objects content ** * * * ** * TEST PLAN * ** * * * ** 0a. Set the ReservesMaxPickUpDelay-syspref to 6 days. 0b. Create reservations, with expirydate in the past, and in the future, and now. Catch some of those to a borrower. 0c. Create reservations without an expirationdate and catch them to borrowers. In the DB, set the waitingdate 2 days to the past for some of them, 4 days to the past for a portion, 6 days to past for some and 8 days past for the rest. 1. Run the cancel_expired_holds.pl-script with --verbose 3 Observe log entries of all the handled reservations and of all the used Calendars (not all Calendars, simply those that were needed). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6