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

[Bug 27866] New: cannot create new printer profiles
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27866 Bug ID: 27866 Summary: cannot create new printer profiles Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org to recerate: -go to Home › Tools › Label creator › Profiles › New printer profile (/cgi-bin/koha/labels/label-edit-profile.pl?op=new) -attempt to save a new printer profile -get an error C4::Creators::Profile::save(): DBI Exception: DBD::mysql::st execute failed: Incorrect integer value: '' for column 'template_id' at row 1 [for Statement "INSERT INTO printers_profile (printer_name, offset_vert, creep_vert, paper_bin, template_id, creep_horz, units, creator, offset_horz) VALUES (?,?,?,?,?,?,?,?,?);" with ParamValues: 0="e", 1=0, 2=0, 3="e", 4='', 5=0, 6="MM", 7='Labels', 8=0] at /kohadevbox/koha/C4/Labels/Profile.pm line 23 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 27911] New: Quick add new patron does not include needed custom fields
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27911 Bug ID: 27911 Summary: Quick add new patron does not include needed custom fields 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 You can require existing fields but if you have custom patron attribute types, you have no way of making them required, thus they are not added with the quick add new patron function. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28311] New: Holds always placed at biblio level
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '21

04 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28311 Bug ID: 28311 Summary: Holds always placed at biblio level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The SIP2 code expects an item barcode as the identifier for placing a hold, but the resulting code in do_hold converts that to a biblio only level hold.. it should be possible to place holds at either bib or item level. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27774] New: Always remove hyphens from ISBN when cataloging
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27774 Bug ID: 27774 Summary: Always remove hyphens from ISBN when cataloging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Actually hyphens are removed from ISBN when using acquisition or z3950 cataloguing or with bulkmarcimport. I propose to add this behavior in TransformMarcToKoha() so MARC data is unchanged, but biblioitems.isbn is without hyphens. This can be used if search using SQL and in reports. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 22591] New: Allow to temporarily exclude patrons from routing lists
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22591 Bug ID: 22591 Summary: Allow to temporarily exclude patrons from routing lists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Target Milestone: --- At the moment it's not possible to temporarily exclude patrons from routing lists. This would be very handy when patrons like internal research staff are known not to be available for a longer time to receive issues (vacation, sickness, remote research...) It could work similarily to suspending holds where you set a date on which to reactivate the routing list memberships. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28444] New: Filter/search box missing above main ILL table on 20.11
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28444 Bug ID: 28444 Summary: Filter/search box missing above main ILL table on 20.11 Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no After upgrading to 20.11.05, the little text box that can be used to search/filter the main table of ILL requests on INTRANET/cgi-bin/koha/ill/ill-requests.pl is gone. This happens on different instances on two separate servers. I have one server running 20.05, and the box is visible there. So far I only see it happening on the ILL form, not for example the holds to pull table or the table of saved reports, where the box is shown as expected. There are no relevant messages in the JS console. I thought it could be interference from custom JS in IntranetUserJS, but I removed everything in there and it still happens. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 25614] New: "Clear filter" button permanently disabled on ILL request list
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25614 Bug ID: 25614 Summary: "Clear filter" button permanently disabled on ILL request list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com On the datatables filtering on the ILL requests page, the "Clear filter" button at the top of the table is permanently disabled, even when the filter text box is populated. It should only be disabled when the text box is empty -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 28458] New: Prefill vendor in "Add from subscription" form
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28458 Bug ID: 28458 Summary: Prefill vendor in "Add from subscription" form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org When adding a subscription to a basket, we arrive on a form where vendor should be prefilled, as we are in a basket attached to a specific vendor. I think it's easier and more convenient for users to empty this search field if needed, rather than fill it for each subscription order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28367] New: Wrong plack condition in C4/Auth_with_shibboleth.pm
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28367 Bug ID: 28367 Summary: Wrong plack condition in C4/Auth_with_shibboleth.pm Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org C4/Auth_with_shibboleth.pm has: if ( any { /(^psgi\.|^plack\.)/i } keys %ENV ) When others have: if ( any { /(^psgi\.|^plack\.)/i } keys %ENV ) This has been highlighted by https://gitlab.com/koha-community/koha-testing-docker/-/issues/249 that introduces a PLACK_WORKERS env vars, and t/Auth_with_shibboleth.t was failing with # Failed test 'checkpw_shib tests' # at t/Auth_with_shibboleth.t line 335. Invalid parameter passed, categorycode= does not exist# Looks like your test exited with 255 just after 5. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 22673] New: Road types only on one address
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '21

03 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22673 Bug ID: 22673 Summary: Road types only on one address Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- When adding/editing a patron, the authorized values for road types only appear next to the first address - if we really want them to be used as authorized values all addresses should have the pull down. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2