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

[Bug 8755] New: Need provision to see the history of currency conversion rate
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '12

11 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8755 Priority: P5 - low Change sponsored?: --- Bug ID: 8755 Assignee: koha-bugs(a)lists.koha-community.org Summary: Need provision to see the history of currency conversion rate Severity: enhancement Classification: Unclassified OS: All Reporter: vimal0212(a)gmail.com Hardware: All Status: NEW Version: rel_3_10 Component: Acquisitions Product: Koha In Administration > Currency need provision to see the previous conversion rate entered. Display it as previous currency rate entries. This is essential for librarians to check currency conversion rate history. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 3456] Serials receipt note
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '12

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3456 Melia Meggs <melia(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off CC| |melia(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3456] Serials receipt note
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '12

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3456 Melia Meggs <melia(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #11738|0 |1 is obsolete| | --- Comment #5 from Melia Meggs <melia(a)bywatersolutions.com> --- Created attachment 12123 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=12123&action=edit [Signed off] Bug-3456-Show-internalnotes-when-receiving-serials.patch I followed the test plan and can see the non-public note on the serials receipt screen. When I deleted the non-public note, it disappeared. Looks good. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5705] New: search 4XX fields in authorities and link to 1XX
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '12

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5705 Summary: search 4XX fields in authorities and link to 1XX Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: eb(a)efdss.org QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Created attachment 3082 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3082 Authority with alternate (see from) terms in current search results In plain English, I would like the ability in both the OPAC and staff interface to 1)allow searching on the 4XX fields in authority records 2)provide a link from an incorrect form of an authority term (4XX) to the correct authority term (1XX) when someone searches on an incorrect one. We have 4XX fields for many alternate spellings, or alternate terms in the authority records, but they don't come up in the Authority search. Currently, If someone searches on the incorrect form, they are not directed to the correct form. This may result in false negative search results. However, when they search on the correct form, the see from (alternate) terms are displayed. A very nice feature (though not critical) would be a window that says something helpful like "did you mean?" with the related 1XX $a field information. -- 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 3

[Bug 8386] New: Error in duplicate detection message for authorities
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '12

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8386 Priority: P5 - low Change sponsored?: --- Bug ID: 8386 CC: jcamins(a)cpbibliography.com, m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: Error in duplicate detection message for authorities Severity: enhancement Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: Cataloging Product: Koha If you create a new authority record and the name already exists in your database, you get a duplicate warning. This is good, but there is a small error in the message: Duplicate record suspected Is this a duplicate of HASH(0x47fa670)? -- You are receiving this mail because: You are watching all bug changes.

1 14

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

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 --- Comment #5 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to comment #4) > I would say we keep borrowers.debarred, but convert it to a boolean value. Convert it *back* to a boolean value! And move the date information into borrower_debarment? > We can then have that value updated each time the debarments table is > altered. Which is when? Is there a line in borrower_debarment for each overdue item which is past the limit? And the table is reviewed each time an item is renewed or checked in?+ > I believe we will then need a nightly cronjob to remove expired > debarments and update borrowers.debarred. I don't understand. Are we talking about a cron job or is this something which updates each time something is checked in or renewed? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

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

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle(a)bywatersolutions.com --- Comment #4 from Kyle M Hall <kyle(a)bywatersolutions.com> --- > Automatic debarment happens only through overdue triggers. Fines may block > certain actions, but those checks are made based on the fine amount and > fine-related system preferences ( OPACFineNoRenewals, maxoutstanding, > noissuescharge). Unless I'm missing something? > > Will this affect the suspension in days feature? Will the debarred column in > the borrowers table stop being used, and all checks for patron debarment be > referred to this new table? Is this going to significantly affect > performance? > > If we keep borrowers.debarred, I suppose checkout performance doesn't have > to be affected. I am concerned that this is going to slow down check-in. > Upon each check-in Koha will have to query the borrower_debarment table to > see if the patron should have the restriction removed? I would say we keep borrowers.debarred, but convert it to a boolean value. We can then have that value updated each time the debarments table is altered. I believe we will then need a nightly cronjob to remove expired debarments and update borrowers.debarred. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 8748] New: Bib # Default Matching Rule
by bugzilla-daemon＠bugs.koha-community.org 10 Sep '12

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8748 Priority: P5 - low Change sponsored?: --- Bug ID: 8748 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: Bib # Default Matching Rule Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Cataloging Product: Koha I think that we should have bib number as a default matching rule in new installs. This is one of those rules that I add all of the time and since the bib number is a Koha field, it just makes sense to have that rule in the system by default. -- You are receiving this mail because: You are watching all bug changes.

1 0

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

10 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 --- Comment #3 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to comment #2) > Since there are numerous reasons for debarment, not just fines, but overdues, > or a manual debarment Automatic debarment happens only through overdue triggers. Fines may block certain actions, but those checks are made based on the fine amount and fine-related system preferences ( OPACFineNoRenewals, maxoutstanding, noissuescharge). Unless I'm missing something? > If a borrower has a least one row in this table, they will be debarred. Will this affect the suspension in days feature? Will the debarred column in the borrowers table stop being used, and all checks for patron debarment be referred to this new table? Is this going to significantly affect performance? > This would require modifying all code that involves debarring, in particular > C4::Overdues::CheckBorrowerDebarred, the borrower editing page, and the > circulation pages. If we keep borrowers.debarred, I suppose checkout performance doesn't have to be affected. I am concerned that this is going to slow down check-in. Upon each check-in Koha will have to query the borrower_debarment table to see if the patron should have the restriction removed? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 8552] New: BiblioAddsAuthorities set to Allow causes Software Error on Z3950 import
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '12

08 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8552 Priority: P5 - low Change sponsored?: --- Bug ID: 8552 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: BiblioAddsAuthorities set to Allow causes Software Error on Z3950 import Severity: enhancement Classification: Unclassified OS: All Reporter: joy(a)bywatersolutions.com Hardware: All Status: NEW Version: unspecified Component: Z39.50 / SRU / OpenSearch Servers Product: Koha Setting the BiblioAddsAuthorities to 'allow' causes a software error when importing a record through Z3950 in Cataloging. Setting it to 'don't allow' allows import to proceed without error. -- You are receiving this mail because: You are watching all bug changes.

1 5