July 2019 - Koha-bugs - lists.koha-community.org

[Bug 23236] New: Remove 'its items may still be processed' in action if no match is found
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23236 Bug ID: 23236 Summary: Remove 'its items may still be processed' in action if no match is found 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I think this is only a string bug, but I'd like a developer to make sure nothing happens behind the scenes. When importing records and looking for duplicate records using record matching rules, there is an option if NO match is found to "ignore incoming record (its items may still be processed)". This doesn't make any sense. Where would the items go if there is no match? To reproduce : 1) Go to tools > Stage MARC for import 2) Browse and choose a file and click on Upload file 3) Go to the Look for existing records in catalog? section 4) Open the drop down for Action if no match is found 5) Note that one option says Ignore incoming record (its items may still be processed) This option should only say Ignore incoming record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 21708] New: Editing a record moves field 999 to first in the marcxml
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21708 Bug ID: 21708 Summary: Editing a record moves field 999 to first in the marcxml 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: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl 1) Import or create a new record. 2) Examine the marcxml of that record in the database - the fields are in the correct numerical order. 3) Edit the record - no need to change any data, just save it. 4) Examine the marcxml in the database - the 999 field is now right after leader and before 001. This is due to TransformHtmlToMarc in C4/Biblio.pm, specifically the $param eq 'biblionumber' case, which pushes the param in the array first, and then the sub uses $record->append_field() Perhaps the array should be sorted by field tag before appending the fields? AFAIK, this doesn't really show up anywhere in Koha, but if you ever edit the records via a script using MARC::Record, new fields cannot be easily inserted into correct position. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 17143] New: Popup Notification for decreaseloanhighholds preference
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17143 Bug ID: 17143 Summary: Popup Notification for decreaseloanhighholds preference Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have an item that meets the holds requirement by the decreaseloanhighholds preference, but doesn’t get a decrease in the actual checkout period; you still get a popup notification that the high demand feature is being used and the loan period will be decreased. The notification shouldn't populate if the decreased loan period matches or is higher than the original loan period. The current behavior in the system looks at the the number of holds and doesn't take the loan periods with an equal value into consideration when enforcing the preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 17693] New: Add option to export deleted bibs in export_records.pl
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17693 Bug ID: 17693 Summary: Add option to export deleted bibs in export_records.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Currently the export_records.pl script has an option to export a list of deleted items, but not deleted biblios. There are cases where such an export would seem useful (at Aristotle University of Thessaloniki we have been using it for a long time), the data is already kept in the deletedbiblio table, so the enhancement is easy to implement as it only requires a couple lines of code in the export script. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 22744] New: 'Do not notify' is really a 'Clear' option
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22744 Bug ID: 22744 Summary: 'Do not notify' is really a 'Clear' option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- 'Do not notify' in messages sort of hints that messages will be prevented, however, when checked it simply clear the other boxes. Hold notices wil generate print even when nothing is selected, so we shouldn't imply that there is an 'Opt out'/'Do not notify' (see bug 5501 for that) The goal of this bug is to simply rename this option -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 21416] New: 'gr' option missing from ZEBRA_LANGUAGE options in koha-sites.conf
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21416 Bug ID: 21416 Summary: 'gr' option missing from ZEBRA_LANGUAGE options in koha-sites.conf Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P3 Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: arouss1980(a)gmail.com Bug 11927 added a Zebra charmap file (sort-string-utf.chr) for Greek language sorting support and also updated the 'koha-create' script to list 'gr' as an available option to the --zebralang argument. However, the main configuration file in /etc/koha/koha-sites.conf (AKA debian/templates/koha-sites.conf in git) does not list 'gr' as an option for the ZEBRA_LANGUAGE variable. I believe 'gr' should be listed among the other language codes, otherwise those who are unaware of Bug 11927 won't know that such support has been added. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 22943] New: The in_ipset syspref name can be confusing.
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22943 Bug ID: 22943 Summary: The in_ipset syspref name can be confusing. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- In bug 14407 we introduced a new system preference to allow limiting the online self checkout system to an IP or IP Range. The preference introduced, however, is called in_ipset which can be confusing (as for those in the know there is a tool in linux called ipset which isn't related to the original bug). We should therefore rename the system preference to in_iprange to more accurately describe it's function. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 23384] New: Calling Koha::Article::Status::* without "use" in Patron.pm can cause breakage
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '20

15 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23384 Bug ID: 23384 Summary: Calling Koha::Article::Status::* without "use" in Patron.pm can cause breakage 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org After spending a while digging into this, I can't explain why it's a problem, but I know that it is and I know how to fix it. During the development of Bug 23112 I encountered a weird problem whereby adding "use Illrequests" to C4/Circulation.pm causes the whole of the app to break with the following error: Bareword "Koha::ArticleRequest::Status::Pending" not allowed while "strict subs" in use at /home/koha-koha/kohaclone/Koha/Patron.pm line 811. Bareword "Koha::ArticleRequest::Status::Processing" not allowed while "strict subs" in use at /home/koha-koha/kohaclone/Koha/Patron.pm line 811. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Illrequest.pm line 37. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Illrequest.pm line 37. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Illrequests.pm line 23. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Illrequests.pm line 23. Compilation failed in require at /home/koha-koha/kohaclone/C4/Circulation.pm line 49. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Circulation.pm line 49. Compilation failed in require at /home/koha-koha/kohaclone/C4/Overdues.pm line 31. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Overdues.pm line 31. Compilation failed in require at /home/koha-koha/kohaclone/C4/Members.pm line 32. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Members.pm line 32. Compilation failed in require at /home/koha-koha/kohaclone/C4/Letters.pm line 30. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Letters.pm line 30. Compilation failed in require at /home/koha-koha/kohaclone/C4/Suggestions.pm line 29. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Suggestions.pm line 29. Compilation failed in require at /home/koha-koha/kohaclone/C4/Acquisition.pm line 25. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Acquisition.pm line 25. Compilation failed in require at /home/koha-koha/kohaclone/C4/Budgets.pm line 27. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Budgets.pm line 27. Compilation failed in require at /home/koha-koha/kohaclone/C4/Biblio.pm line 94. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Biblio.pm line 94. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Biblio.pm line 27. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Biblio.pm line 27. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Biblios.pm line 26. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Biblios.pm line 26. Compilation failed in require at /home/koha-koha/kohaclone/Koha/ArticleRequest.pm line 26. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/ArticleRequest.pm line 26. Compilation failed in require at /home/koha-koha/kohaclone/Koha/ArticleRequests.pm line 26. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/ArticleRequests.pm line 26. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Patrons.pm line 28. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Patrons.pm line 28. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Item.pm line 33. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Item.pm line 33. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Items.pm line 26. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Items.pm line 26. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Checkout.pm line 28. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Checkout.pm line 28. Compilation failed in require at /home/koha-koha/kohaclone/Koha/Checkouts.pm line 25. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/Koha/Checkouts.pm line 25. Compilation failed in require at /home/koha-koha/kohaclone/C4/Auth.pm line 37. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/C4/Auth.pm line 37. Compilation failed in require at /home/koha-koha/kohaclone/admin/preferences.pl line 23. BEGIN failed--compilation aborted at /home/koha-koha/kohaclone/admin/preferences.pl line 23. The reference to "preferences.pl" is a red herring and just reflects the page you're on at the time. The rest of the error is the same regardless of the page. Poking around, I've not been able to determine why the usage of Illrequest in Circulation.pm would cause Patron.pm to suddenly complain about Koha::ArticleRequest::Status::* calls being barewords. With Modern::Perl the strict subs pragma should catch that sort of stuff. So I've really got no idea what's going on. Anyway, the obvious fix is to add "use Koha::ArticleRequest::Status;" to Patron.pm, which is what the patch for this bug is going to do. I just wish I understood why it's a problem in the first place! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 17464] New: Order deny, allow / Deny from all was deprecated in Apache 2.4 and is now a hard error
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17464 Bug ID: 17464 Summary: Order deny,allow / Deny from all was deprecated in Apache 2.4 and is now a hard error Change sponsored?: --- Product: Koha Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: gmcharlt(a)gmail.com Reporter: bob-ewart(a)bobsown.com QA Contact: testopia(a)bugs.koha-community.org The Allow, Deny and Order directives were deprecated in Apache 2.4 and are no longer recognized. Order deny,allow Deny from all Should be: Require all denied lines 36/37 and 169/170 in koha-httpd.conf should be changed This is in Koha compiled from source and appears in most of the versions I've tried. Also add: <Directory '/usr/share/koha'> Require all granted </Directory> or you will get an 'access forbidden' error If using plugins also add: <Directory '/var/lib/koha'> Require all granted </Directory> -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 21879] New: Code cleaning in printinvoice.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21879 Bug ID: 21879 Summary: Code cleaning in printinvoice.pl 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: kohadevinim(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com While working on bug 19489, we realized that some lines are nor necessary anymore, hence we will clean those. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21