December 2017 - Koha-bugs - lists.koha-community.org

[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 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

[Bug 16248] New: ModZebra doesn't update zebraqueue if ES is enabled
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '20

10 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16248 Bug ID: 16248 Summary: ModZebra doesn't update zebraqueue if ES is enabled 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 The zebraqueue table should still be populated with updates if ES is enabled, so the Zebra indexer keeps the Z39.50/SRU indexes up to date. To reproduce: - Set SearchEngine = Elasticsearch - Watch for zebraqueue changes $ watch -n 0.5 'echo "SELECT COUNT(*) FROM zebraqueue WHERE done=0" | sudo koha-mysql kohadev' - Call touch_all_biblios.pl to simulate record changes $ sudo koha-shell kohadev ; cd kohaclone $ perl misc/maintenance/touch_all_biblios.pl -v => FAIL: Notice the watch is not changing the number of records to be indexed. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15972] New: Make it possible to include additional title information in notices (such as 245$b)
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '20

10 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15972 Bug ID: 15972 Summary: Make it possible to include additional title information in notices (such as 245$b) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For some titles the 245$a (MARC21) is not specific enough and it would be necessary to include the 245$b information in the notices, that is currently not mapped in the database. Apart from 245$b (remainder of title) other information like 245$n/$p for volumes would be nice to have. This was reported by a library using serial claims - where the title is often the same and the correct serial can only be identified with the help of additional information. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 17854] New: Print Slip and Close button
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '20

04 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17854 Bug ID: 17854 Summary: Print Slip and Close button Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Would like to see an enhancement on the clear screen (X) button on patron records. It would be great if it were replaced with a button with preference settings that would have the following options: Close Print Slip and Close Print Quick Slip and Close It would also be great if it could have a side action arrow giving you access to the other options that are not defaulted. This feature would help with staff closing accounts (clearing screen) when done, and making slip printing stand out a little better. It would also be a streamlined workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 17532] New: koha-shell does not propagate the error code
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '20

01 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17532 Bug ID: 17532 Summary: koha-shell does not propagate the error code Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 18330] New: REST API: Date-time handling
by bugzilla-daemon＠bugs.koha-community.org 29 May '20

29 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18330 Bug ID: 18330 Summary: REST API: Date-time handling Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Swagger2 wants dates and date-times as defined in RFC3339, https://xml2rfc.tools.ietf.org/public/rfc/html/rfc3339.html#anchor14 Make sure each object property has a format date or date-time defined where needed. We should include information on time zone and use an appropriate separator "T" between date and time, e.g.: 2017-03-24T14:00:00+02:00 2017-03-24T12:00:00Z -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30