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

[Bug 25221] New: Imported records are not checked for accuracy
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '24

02 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25221 Bug ID: 25221 Summary: Imported records are not checked for accuracy Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When you create a new bib record, Koha checks if certain fields are filled out. When you import a bib record, Koha does not check if that record has those fields filled out. I would suggest that when a record is imported, it either needs to be taken immediately into editing so that Koha can catch issues, or it needs to be put into a quarantine state, and unusable anywhere in the system until it is edited and saved. When importing a bib for an order, since you are dealing with a single record, I could see how going straight into editing after importing could work. However, if you are importing bibs through an batch import tool, if the process isn't already checking for issues or missing fields, these items should be set in quarantine and require the cataloger to edit the record to remove it from quarantine. This process would address problems elsewhere in Koha where incomplete or compromised records cause an error in Koha or in a process that can't complete due to a faulty record. I'm not a cataloger, but this seems like a reasonable workflow for bringing outside records into your own system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 24967] New: Allow final user to choose ordering column
by bugzilla-daemon＠bugs.koha-community.org 01 Jan '24

01 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24967 Bug ID: 24967 Summary: Allow final user to choose ordering column Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: pascale.nalon(a)mines-paristech.fr QA Contact: testopia(a)bugs.koha-community.org It would be fine, if members of staff, who have not permissions to modify a SQL requests, but only to run them, could choose the column and the way (ASC or DESC) to order the pre-builded request -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25112] New: Koha::CirculationRules->set_rules should handle scopes per rule
by bugzilla-daemon＠bugs.koha-community.org 01 Jan '24

01 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25112 Bug ID: 25112 Summary: Koha::CirculationRules->set_rules should handle scopes per rule Change sponsored?: --- Product: Koha Version: unspecified 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: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org Koha::CirculationRules->set_rules is currently too complicated to use. Right now, in order to specify multiple rules at once, they must all be rules that accept the same set of scopes. Otherwise we can get this type of errors: 1/9 set_rule cannot set 'holds_per_record' for a 'checkout_type'! at t/db_dependent/Circulation/GetHardDueDate.t line 215. Validating scopes at set_rule() is good, but set_rules() should examine each rule and pass the correct scope to set_rule() instead of passing all scopes to every rule like it is doing now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 25134] New: Return claims column should not be shown if ClaimReturnedLostValue is not set
by bugzilla-daemon＠bugs.koha-community.org 01 Jan '24

01 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25134 Bug ID: 25134 Summary: Return claims column should not be shown if ClaimReturnedLostValue is not set Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the checkouts table shown on circulation and patron details the "Return claims" column should be wrapped in a conditional checking for the presence of a value in the ClaimReturnedLostValue system preference. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 25158] New: Introduce koha-memcached
by bugzilla-daemon＠bugs.koha-community.org 01 Jan '24

01 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25158 Bug ID: 25158 Summary: Introduce koha-memcached Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net "Interacting" with memcached has been a problem, since pretty much the only thing we can easily do with it is restart it to empty it of all cached values. This is less than ideal, especially in a multi-tenant setup where several Koha instances share the same server, and also the same memcached server. This is especially true when sessions are saved in memcached, which means that "flushing" (restarting) the cache for one site terminates all active sessions for all sites. koha-memcached tries to fix this by providing a convenient script to list all keys in memcached, get their values and delete them. This is done as a script similar to koha-mysql etc. Now, while researching this I read that doing things like listing all keys in memcached might not always be possible. It does seem to work in the testing I have done so far though. Maybe a single instance of memcached on localhost is less problematic in this respect then if you have a cluster of servers etc? More opinions on this is needed. The script relies on Memcached::libmemcached and memcdump. This is mostly a proof of concept, with some rough edges that need to be worked on a bit more, *if* this approach is something we think is worth pursuing. Feedback is most welcome! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 25289] New: CalculateFinesOnReturn does not affect SIP2
by bugzilla-daemon＠bugs.koha-community.org 01 Jan '24

01 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25289 Bug ID: 25289 Summary: CalculateFinesOnReturn does not affect SIP2 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com A library reported this. I have not investigated properly, but grep'ing for the syspref in C4/SIP/ gives no results. I would say this is surprising. Either the old syspref should apply to SIP2, or there should be a separate syspref like CalculateFinesOnReturnSIP2. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25338] New: Koha checks items in when lost fee waived/paid
by bugzilla-daemon＠bugs.koha-community.org 01 Jan '24

01 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25338 Bug ID: 25338 Summary: Koha checks items in when lost fee waived/paid Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org To replicate: 1) Check out an item to patron and have item go lost and charge for item. 2) Renew item. Notice status is not changed. Fee is not removed. 3) Remove lost status. Notice fee is not removed. Item remains on patron account. 4) Waive or pay fee. Notice the item is checked! What the heck! There are a few things wrong here. First, if an item is renewed, the lost status should at least be removed. Maybe there needs to be a setting for this, and whether or not the fee is removed if the item is renewed. Second, if you remove the lost item status, the fee remains. Again, maybe there needs to be a setting for that to decide if the fee should be remove. Third, and this is THE BIGGEST ISSUE I have with this. Under no circumstances should waiving or paying for a fee change the status of the item from checked out to checked in. Maybe there should be an option, but I can't think of a good reason for this to happen, ever. Would like to have a quick fix for this last issue, ASAP, especially since we had extended due dates with the new batch tool due to COVID-19, and we are going to be correcting a lot of these. Currently, the ONLY workaround I've seen is that I have to watch the item after waiving the fee, and check it back out to the patron. This is a good way to lose track of items that are out, and very easy for someone to miss. Because of that, I am marking this as critical. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 24577] New: API schema merging breaks with older versions of JSON module
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '23

31 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24577 Bug ID: 24577 Summary: API schema merging breaks with older versions of JSON module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com I discovered this while deploying a plugin that defines an API route. If the installation is using a version of the JSON module < 2.90, schema merging doesn't work correctly, these are the sort of errors that were being generated during validation of the merged schema: { 'path' => '/paths/~1contrib~1ill_availability_unpaywall~1ill_availability_search_unpaywall/get/parameters/0', 'message' => 'oneOf failed: oneOf failed: Properties not allowed: type. oneOf failed: (Not in enum list: header.. Expected boolean - got JSON::XS::Boolean.) (Not in enum list: formData.. Expected boolean - got JSON::XS::Boolean.) Expected boolean - got JSON::XS::Boolean. (Expected boolean - got JSON::XS::Boolean.. Not in enum list: path.) Properties not allowed: name, required, type, description, in.' } Pretty nonsensical and a nightmare to try and get to the bottom of. I was seeing this using JSON 2.61. I believe the change that was implemented in 2.90 that we're dependent on, is the top one listed here: https://metacpan.org/changes/release/MAKAMAKA/JSON-2.90 Koha is currently specifying 2.07 as the required version. I'm wondering if it is worth moving this to 2.90. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 24580] New: Allow patron_emailer or parallel structure to generate custom print notices from report output
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '23

31 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24580 Bug ID: 24580 Summary: Allow patron_emailer or parallel structure to generate custom print notices from report output 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 16149 adds the ability to combine report results with a custom notice to generate emails. Many libraries do not reliably have email addresses for their patrons and could use a method to generate print notices. This could be a failover from email to print (as overdues do) or a separate cron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 24562] New: addbiblio.pl overloading CPU
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '23

31 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24562 Bug ID: 24562 Summary: addbiblio.pl overloading CPU Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jawad_makki(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello. Sometimes during the day, addbiblio.pl is overloading CPU (100%) and therefore it is making Koha completely not responding for few minutes (can reach 20 minutes). in apache2 log, the response time for "POST /cgi-bin/koha/cataloguing/addbiblio.pl HTTP/1.1" is reaching gateway timeout few times per day. below are some errors retrieved from plack-error.log Use of uninitialized value $mode in string ne at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 845. Use of uninitialized value $searchid in concatenation (.) or string at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 876. Koha version 19.11 , running on debian 9 memcached and plack are enabled. this problem was also in 18.11, we have upgraded koha to 19.11 but the problem is still occuring Any help -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33