August 2021 - Koha-bugs - lists.koha-community.org

[Bug 28264] New: Transaction type is empty is cash register statistics wizard report
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '22

07 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28264 Bug ID: 28264 Summary: Transaction type is empty is cash register statistics wizard report Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Hi all! When I do a report using the statistics wizard, the transaction type doesn't appear. I think maybe this has something to do with the "new" structure for accounttypes which are now separated in credit_type_code and debit_type_code... To test: 1) Go into a patron file and add some manual fees and pay them 2) Go to Reports > Statistics wizards > Cash register 3) In the form, choose Transaction type: All transactions 4) Click "Submit" 5) Note that the Transaction type column is empty 6) In the form, choose Output: To a file 7) Click "Submit" 8) Open the file in a spreadsheet software (I use LibreOffice) 9) The Transaction type column is empty A client reported this to me after we upgraded them from 19.05.04 to 20.05.08. In 20.05 (in the client's db), the Transaction type column is filled when viewing the report in the browser, but when we export the report, it's empty. In my master (default db), the transaction types don't appear in either cases. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 26381] New: Koha should provide Koha plugins with a template to use with Template::Toolkit WRAPPER
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '22

07 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26381 Bug ID: 26381 Summary: Koha should provide Koha plugins with a template to use with Template::Toolkit WRAPPER Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, Koha plugins have to built their own templates from scratch. I'm proposing that Koha provides a BLOCK or a template file that Koha plugins can then use with the Template::Toolkit WRAPPER directive to minimize the amount of boiler plate they have to use. Here is an example of a very simple "plugin_wrapper" [% BLOCK plugin_wrapper %] [% INCLUDE 'doc-head-open.inc' %] <title>Koha: [% name %]</title> [% INCLUDE 'doc-head-close.inc' %] </head> <body> [% INCLUDE 'header.inc' %] [% INCLUDE 'cat-search.inc' %] <div id="breadcrumbs"><a href="/cgi-bin/koha/mainpage.pl">Home</a> &rsaquo; <a href="/cgi-bin/koha/plugins/plugins-home.pl">Plugins</a> &rsaquo; [% breadcrumb %]</div> <div id="doc3"> [% content %] [% INCLUDE 'intranet-bottom.inc' %] [% END %] Then, in my report-step1.tt file, all I need to include is the following: [% WRAPPER plugin_wrapper name = 'My Plugin' breadcrumb = 'My Plugin' %] <div>Plugin content</div> [% END %] I've already tested this a little bit, and it's beautiful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 23330] New: deleteditemsstocknumberidx should not be a unique index
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '22

07 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23330 Bug ID: 23330 Summary: deleteditemsstocknumberidx should not be a unique index Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, deleteditemsstocknumberidx is a unique index, which means that an item will fail to delete if its "Inventory number" already exists in the deleteditems table. Its counterpart itemsstocknumberidx was renamed to itemstocknumberidx in version 3.03.00.042 (dating from April/May 2011) and made non-unique. I've worked on Koha since early 2012 and only today have I had someone stung by this problem. They've been storing "Copy number" in "Inventory number" for some reason, and it's caught them out. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 28758] New: Undefined subroutines in C4/ImportBatch.pm (bug 17600)
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '22

06 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28758 Bug ID: 28758 Summary: Undefined subroutines in C4/ImportBatch.pm (bug 17600) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 20421] New: Inform staff that patron does have the title checked out during placing hold
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '22

06 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20421 Bug ID: 20421 Summary: Inform staff that patron does have the title checked out during placing hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 28200] New: Net::Netmask 1.9104-2 requires constructor change for backwards compatibility
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28200 Bug ID: 28200 Summary: Net::Netmask 1.9104-2 requires constructor change for backwards compatibility Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As Jonathan and David noted in Bug 25950, Net::Netmask needs a constructor change from 1.9104-2 in order to accept abbreviated formats. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 26055] New: Advanced Editor Rancor should use "visibility" and not "mandatory" for drawing new records
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26055 Bug ID: 26055 Summary: Advanced Editor Rancor should use "visibility" and not "mandatory" for drawing new records Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The Advanced Editor (Rancor) uses a tag's mandatory flag to decide whether to show in the UI when showing an editor for a new record. This doesn't make 100% sense, since often a cataloguer will also want to see optional fields (like 500) by default to serve as a prompt. In systems like Horizon, one refers to these as "templates". You have a separate set of typical fields for books, journals, DVDs, etc. You don't have to fill in all those fields, but they're the typical fields that you would use for them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 25523] New: Address lintian warnings when packaging Koha
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25523 Bug ID: 25523 Summary: Address lintian warnings when packaging Koha Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net I notice that lintian raises a lot of warnings when building Koha packages. Some of these like the following can be safely ignored: W: koha-common: embedded-javascript-library usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/lib/jquery/plugins/jquery.cookie.min.js please use libjs-jquery-cookie W: koha-common: embedded-javascript-library usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/lib/jquery/plugins/jquery.metadata.min.js please use libjs-jquery-metadata But then there are others that would be easy wins: W: koha-common: executable-not-elf-or-script usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/admin/additional-fields.tt W: koha-common: executable-not-elf-or-script usr/share/koha/lib/C4/HoldsQueue.pm W: koha-common: executable-not-elf-or-script usr/share/koha/intranet/cgi-bin/installer/data/mysql/mandatory/subtag_registry.sql I'm thinking about slowly tackling these... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 22344] New: Limits cannot contain parentheses
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22344 Bug ID: 22344 Summary: Limits cannot contain parentheses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au Target Milestone: --- I've noticed an authorised value of category LOC can't have parentheses in it. If it does, the search silently fails... I'm guessing it doesn't even make it from the ZOOM library in Koha over the connection to Zebra. I'm going to explore in a moment, but people have noticed this and kind of worked around it with #5693 and #7031. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 23457] New: Placing holds on multiple items in a bib record
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '22

05 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23457 Bug ID: 23457 Summary: Placing holds on multiple items in a bib record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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 I am not finding a straight forward way to place multiple items in a bib record on hold at once, if there is a way at all. We have multiple items in the same record that we reserve for various reasons. However, we have to place them on hold, one at a time. If the system allows you to place multiple holds on items in a record, there should be a way to place them all at once. Some way to select, either with check boxes or the cart, and place them on hold. This method should also include a way to set individual notes for each hold, or set one note and duplicate to the rest. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8