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

[Bug 19508] New: When returning a lost item, Koha claim to have applied a refund when it has not
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '20

02 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19508 Bug ID: 19508 Summary: When returning a lost item, Koha claim to have applied a refund when it has not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1) Create a new item 2) Set it to 'missing' from the edit item screen (you might have to change the visibility setting of this subfield in order to do that) 3) Return the item 4) Verify that Koha reports: A refund has been applied to the borrowing patron's account. This message should only be shown, when an actual refund has been applied. It would also be nice to link to the patron in question in the message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20194] New: Display items.ccode as well as both biblioitems.itemtype and items.itype in circulation screens
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '20

29 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20194 Bug ID: 20194 Summary: Display items.ccode as well as both biblioitems.itemtype and items.itype in circulation screens 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: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment in circulation screens only one "item type" is displayed, biblioitems.itemtype or items.itype, depending on the item-level_itypes system preference. It is however possible for libraries to use both, biblioitems.itemtype to qualify the record, and items.itype to qualify the item itself. In such a scenario only one of the two will be displayed on the circulation screen. It is also possible for libraries to use items.ccode to further refine the description of their items, but this information is not displayed on circulation screens. This enhancement will make all this information more visible in circulation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 16528] New: Add ability to parallel process fines to fines.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '20

29 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16528 Bug ID: 16528 Summary: Add ability to parallel process fines to fines.pl 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On very large sites with thousands of overdue items, fines.pl may take an incredibly long time to complete. It may be possible to speed up fines.pl by allowing it to fork children that run in parallel. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 19588] New: There is no ILL requests history
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '20

25 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19588 Bug ID: 19588 Summary: There is no ILL requests history Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 7317 When a request is deleted, the row is removed from illrequests. Is that expected? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 [Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 17232] New: Subfield default values are not ported when creating a new framework from an old one
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '20

24 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17232 Bug ID: 17232 Summary: Subfield default values are not ported when creating a new framework from an old one Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: joachim.ganseman(a)ehb.be QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When creating a new bibliographic MARC21 framework from an old one, any default values set for subfields in the old framework are not ported to the newly created framework. They have to be reset. To reproduce: - Set a default value in an existing bibliographic MARC21 framework, e.g. 040$a to your institution's MARC code. - Create a new framework based on that one - Create a new record using that new framework: the default value is not set. - Upon checking the database table marc_subfield_structure (e.g. WHERE tagfield = 40 and tagsubfield = 'a'), notice there is no defaultvalue set in that subfield in the new framework. This issue occurs in a package install of version 16.05 on Debian. -- You are receiving this mail because: You are watching all bug changes.

1 21

[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 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 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 18369] New: Broken title link in UNIMARC catalog search results table
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '20

13 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