October 2018 - Koha-bugs - lists.koha-community.org

[Bug 21256] New: Duplicate Record error when Creating New Record
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '20

22 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21256 Bug ID: 21256 Summary: Duplicate Record error when Creating New Record Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When creating a new record in Koha 17.11.08, a duplicate message will appear claiming to have found a match. A match should be found on an exact Title/ Author combination, however, it appears to be finding a match on any word found within the 245. For example: title "Kelly" will match on a Book called " Love of Neighbor as Great Commandment in the Time of Jesus: Grasping at Straws in the Hebrew Scriptures" with the 245c "henry Ansgar Kelly" - this is not expected behavior. Another example : for a new title of just "Test", this will bring back a duplicate of a title with the word "test" in it, this is what is in the 245a "Temporal Stability of the Francis Scale of Attitude toward Christianity Short-Form among 10- to 12-Year-Old English Children: Test-Retest Data over 15 Weeks" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 19705] New: DecreaseLoanHighHolds.t is still failing randomly
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '20

19 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19705 Bug ID: 19705 Summary: DecreaseLoanHighHolds.t is still failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org https://jenkins.koha-community.org/job/Koha_Master_D8/298/console # Failed test 'Static mode should exceed threshold' # at t/db_dependent/DecreaseLoanHighHolds.t line 125. # got: '0' # expected: '1' # Failed test 'Should have duration of 1' # at t/db_dependent/DecreaseLoanHighHolds.t line 127. # got: '0' # expected: '1' # Failed test 'due_date should be a DateTime object' # at t/db_dependent/DecreaseLoanHighHolds.t line 128. # got: '' # expected: 'DateTime' Can't call method "hour" on an undefined value at t/db_dependent/DecreaseLoanHighHolds.t line 131. # Looks like your test exited with 255 just after 5. [18:52:27] t/db_dependent/DecreaseLoanHighHolds.t ......................... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 15/17 subtests -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 21565] New: SCO checkout confirm language
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '20

17 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21565 Bug ID: 21565 Summary: SCO checkout confirm language Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Upon completion of SCO a user clicks "finish" which invokes a JS alert which says "Would you like to print a receipt?". The options are "Cancel" and "OK". This language is confusing to some patrons who think "Cancel" will cancel the entire SCO transaction. Changing this language to "Yes" and "No" would make it much clearer. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 18519] New: Add ability to skip irrelevant dates in Koha::Calendar
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '20

17 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18519 Bug ID: 18519 Summary: Add ability to skip irrelevant dates in Koha::Calendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We've seen occurrences of fines.pl and overdue_notices.pl slowing down when there are a large number of (usually old) entries in special_holidays table. Apparently, we're checking each candidate day against the whole fines calendar -- this is unnecessary, as both fines and overdue notices are are bounded; we only need to check the calendar enteries between the current day and the relevant letter delay (for overdue notices) or between the day the item went overdue and the current day (for fines). If we could pass in a start and end date, we could eliminate this overhead. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 21137] New: Remplace BORROWER_INFO and USER_INFO with logged_in_user
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '20

16 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21137 Bug ID: 21137 Summary: Remplace BORROWER_INFO and USER_INFO with logged_in_user Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 18403 We now have a Koha::Patron object sent to the templates, logged_in_user. It must be used everywhere patron's info are needed. BORROWER_INFO and USER_INFO can be replaced using it. See commit d2f2590c894efca417112795e05248dbd16636f5 Bug 18403: Send logged_in_user to template from C4::Auth Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18403 [Bug 18403] Hide patron information if not part of the logged in user library group -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 20483] New: Allow users to delete specific borrower history entries, independent of of anonymising data
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '20

16 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20483 Bug ID: 20483 Summary: Allow users to delete specific borrower history entries, independent of of anonymising data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Borrowers should be able to granularly delete or anonymise their own issuing histories. Possibly we should only remove what the item was, not the entire record of the checkout. For example, if someone had issued 10 books in the past, but didn't want "the three little pigs" to turn up in their history anymore, they should be able to delete this. This borrower could either show a statistic of "10 issues" with titles for 9, or we could remove the record of the issue altogether. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 19833] New: Kill the "biblios"
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '20

15 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19833 Bug ID: 19833 Summary: Kill the "biblios" 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org For bibliographic record we use three string variants: - biblio - biblio record - biblliographic record According to our terminology we should always use "bibliographic record", we should modify it in all templates. https://wiki.koha-community.org/wiki/Terminology -- You are receiving this mail because: You are watching all bug changes.

1 72

[Bug 21086] New: Wrong mock of DateTime->now in tests
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '20

13 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21086 Bug ID: 21086 Summary: Wrong mock of DateTime->now in tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 20287, 19705 prove t/db_dependent/DecreaseLoanHighHolds.t t/db_dependent/DecreaseLoanHighHolds.t .. 1/17 Can't locate object method "truncate" via package "80" (perhaps you forgot to load "80"?) at /home/vagrant/kohaclone/C4/Circulation.pm line 3497. What is happening: We mock DateTime->now in the script to avoid the date comparaisons to fail on slow servers (see bug 19705). my $now_value = DateTime->now(); my $mocked_datetime = Test::MockModule->new('DateTime'); $mocked_datetime->mock( 'now', sub { return $now_value; } ); Since bug 20287, we have the following calls: Koha::Patron->store => Koha::Patron::Category->get_expiry_date which does: 221 return $date->add( months => $self->enrolmentperiod, end_of_month => 'limit' ); as enrolmentperiod is generated by t::lib::TestBuilder, it can be quite big, and so the date change from one call to the others. The failure is actually coming from the date becoming > 9999, which is not handled correctly, on purpose, by Koha::DateUtils (infinite) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19705 [Bug 19705] DecreaseLoanHighHolds.t is still failing randomly https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20287 [Bug 20287] Move AddMember and ModMember to Koha::Patron -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 18369] New: Broken title link in UNIMARC catalog search results table
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18369 Bug ID: 18369 Summary: Broken title link in UNIMARC catalog search results table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: synapse.ova(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In staff client, «Search the catalog» returns a table, where biblio title has a broken link (biblionumber is absent), yet other links works good (Holds, Edit Record, Edit items, OPAC view) Steps to Reproduce: In staff client, search the catalog (Cataloging → «Search the catalog» (/cgi-bin/koha/catalogue/search.pl)) Actual Results: Title of the biblio has a link, that doesn't have biblionumber Expected Results: Title of the biblio should have a link with a proper biblionumber at the end Additional Information: Each biblio in the results table is shown by XSL transformation of MARC data. XSL (\intranet-tmpl\prog\en\xslt\UNIMARCslim2intranetResults.xsl) prepares a link, and adds a biblionumber, that it expects to get from controlfield 001. But since this field could be either empty or contain something different than biblionumber (see https://lists.katipo.co.nz/public/koha/2015-September/043652.html) it is better to pass the biblionumber to this script. This script is already receiving sysprefs (that is not according to marcxml standart), so I suggest to pass the biblionumber the same way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 20391] New: Koha creates new authorities for 100 & 700 tags bringing in the relator term into the new authority
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '20

11 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20391 Bug ID: 20391 Summary: Koha creates new authorities for 100 & 700 tags bringing in the relator term into the new authority Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Current behavior for when you have the system preference for AutoCreateAuthorities set to generate and BiblioAddsAuthorities set to allow, when creating new authority records for 100 & 700 tags, it also creates relator terms. Steps to recreate: When you save a bib record in the basic editor, authorities are connected or created if the system does not have that authority. When Koha creates new authorities for 100 & 700 tags for people it also brings the relator term into the new authority. Most people do not want relator terms in their authority records so they need to inspect their personal authorities and bring in the proper authority from LC (or another source). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6