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

[Bug 20468] New: Multiselect on staff article requests form
by bugzilla-daemon＠bugs.koha-community.org 27 Jul '20

27 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20468 Bug ID: 20468 Summary: Multiselect on staff article requests form 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 24363] New: Datepicker calendar is not sexy on additem.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '20

24 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24363 Bug ID: 24363 Summary: Datepicker calendar is not sexy on additem.pl 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 96893 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=96893&action=ed… Screenshot showing the date acquired field in additem I just wanted to mention that the datepicker calendar icon looks weird in the additem form (probably elsewhere too). Could we make it bigger and centered? Also the ellipsis (...) is not next to the box as it was before. -- You are receiving this mail because: You are watching all bug changes.

1 59

[Bug 24869] New: When Marc Record uses brackets in the publication Year the value is stored in the database as null
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '20

24 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24869 Bug ID: 24869 Summary: When Marc Record uses brackets in the publication Year the value is stored in the database as null Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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 For multiple reasons are < or [ used in cataloging dates that are either unknown or with a range. These are three examples that do not work or get stored properly in Koha and the database. [19--] <1981-> [1981] Currently, if a publication year has the hard brackets or the hungry alligators with a year, the date does not get stored in the database as a value, but it stored as null. It would be nice if Koha were to display the year regardless of the < or [ . If a year is presented like this [19--], Koha should use the value of the year with 1900 in the database, and in a case such as this <1981->, it should be 1981. The database holds these values as NULL. When an item search in Koha is done with a record with one of these values, the publication year will display as 0, which is not helpful to a library when needing the publication date stored in the Marc Record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24352] New: OpacItemLocation is buggy
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '20

24 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24352 Bug ID: 24352 Summary: OpacItemLocation is buggy 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The different settings from the OpacItemLocation don't appear to work correctly. When "collection" is selected, collection is not visible, but a label 'Location(s)' shows up? The callnumber never showed for me in my testing? -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 21067] New: Under plack, 500 errors only show as "Internal Server Error"
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '20

23 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21067 Bug ID: 21067 Summary: Under plack, 500 errors only show as "Internal Server Error" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When plack is not running, 500 errors will show the error message of the perl file where the error occurred, as well as a contact email address, something like this: 500 Internal Server Error Use of uninitialized value within @itemnumber in string ne at /usr/share/koha/intranet/cgi-bin/reserve/modrequest.pl line 70. To report a broken link or any other issue, please contact the Koha Administrator. (I think the text is actually from koha-tmpl/intranet-tmpl/prog/en/modules/errors/errorpage.tt) Under plack, all we see is Internal Server Error This means that a) Errors are less likely to be reported to the server administrator because there's no mailto. b) We can't immediately see the error message when the error is reported. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20437] New: Force requirement for HTTP::OAI 3.27
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '20

23 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20437 Bug ID: 20437 Summary: Force requirement for HTTP::OAI 3.27 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net Until HTTP::OAI is patched so it actually works, and bug 17704 fixes the API change Koha-side, we need to explicitly pull the right version. Otherwise people using Debian 9+ derived distros (Ubuntu 16.04+) are seeing production issues. This implies packaging our custom libhttp-oai-perl distribution in the meantime. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 24657] New: Fix tests of bug 22284 - Groups of pickup locations for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '20

22 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24657 Bug ID: 24657 Summary: Fix tests of bug 22284 - Groups of pickup locations for holds 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: agustinmoyano(a)theke.io QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Tests in bug 22284 had conditions where they randomly fail -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 24443] New: Consider NULL as 0 for issues in items search
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '20

21 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24443 Bug ID: 24443 Summary: Consider NULL as 0 for issues in items search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In items search, we can filter by items issues count, data coming from items.issues. Most of the time, for an item with no issues this column contains NULL. This enhancement proposes to consider NULL as 0 to allow searching items with no issues. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 17697] New: Notes Blacklist only blacklists fields on the OPAC main detail view ( not the OPAC MARC display)
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '20

20 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17697 Bug ID: 17697 Summary: Notes Blacklist only blacklists fields on the OPAC main detail view (not the OPAC MARC display) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org To replicate: Add a note to a field in a record (let's say 500) Verify the note shows in both the OPAC Detail and OPAC MARC views Add a blacklist entry to the NotesBlacklist system preference for field 500 Verify the note does not appear on the OPAC detail Verify the note DOES appear on the OPAC MARC detail. Blacklisted notes shouldn't display anywhere in the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 21292] New: Patron Deletion Tool
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '20

20 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21292 Bug ID: 21292 Summary: Patron Deletion Tool Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 78312 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=78312&action=ed… this is what Koha produces from a patron list of 3 people when only 1 could be deleted. Currently, the patron deletion tool will not delete patrons who has fines and/or checkouts. Unfortunately, the tool does not indicate the patrons that were not deleted because of these constraints. It would be nice to have Koha identify the # of patrons that were requested to be deleted, the number of patrons successfully deleted (with possibly a list) and the number and specifics of the patrons that could not be deleted due to checkouts/fines. This would give clear indication what was accomplished with this tool for libraries. The current functionality of entering patrons that have checkouts/fines that have been requested to be deleted, Koha all but ignores those patrons and doesn't say anything. For example, if I had a patron list of 3 patrons and I requested Koha delete this entire list of patrons. If 2 of those patrons had fines/checkouts, Koha would only display 1 patron deleted. This would not be a link to the patron that was deleted - just a simple number. In addition, the manual does not have correct information regarding this tool - as it indicates - this is quoted from the 17.11 manual : "Important Patrons with outstanding fines or items checked out are not saved. They are not completely removed from the system (they are only moved to the delete_borrowers table), but this tool does not provide as many checks as one may desire." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2