November 2018 - Koha-bugs - lists.koha-community.org

[Bug 19789] New: Remove some indirect DBIx calls from updatedatabase
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '19

11 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19789 Bug ID: 19789 Summary: Remove some indirect DBIx calls from updatedatabase Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Triggered by a comment on 19096. What happens when DBIx schema does not match table design? Add a field to schema file that does not exist => Koha::Object->new and store still works, Koha::Objects->search still works but an actual fetch by calling ->next is enough to crash. DBD::mysql::st execute failed: Unknown column 'me.iserniet' in 'field list' Add a field to the table but not to the schema file => Seems to work still Dubious lines in updatedatabase L12389 Koha::SearchEngine::Elasticsearch->reset_elasticsearch_mappings; This includes Koha Objects calls to Koha::SearchFields and Koha::SearchMarcMaps. The sub add_to_search_marc_maps in Koha::SearchField puzzles me. Does this work, why is there no test associated with it ? Any (future) new column in search fields or search marc maps may lead to a crash at 3.23.00.050 L13526 and context: Koha::Number::Price->new( $order->{rrp} )->round; Only new calls seem to be fine. But might be tricky. L14364 and context: Koha::Holds->search({ found => 'W', priority => 0 }); Any future change in reserves table may lead to a crash on the next statement in 16.12.00.032. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 20493] New: SIP2 sending blank Title Identifier and Due date while Renew the books through Selfcheck
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20493 Bug ID: 20493 Summary: SIP2 sending blank Title Identifier and Due date while Renew the books through Selfcheck Change sponsored?: --- Product: Koha Version: 17.05 Hardware: PC OS: Windows Status: NEW Severity: critical Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: aniltiwari86(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Created attachment 73418 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=73418&action=ed… SIP2 Logs Hi, When we are renewing the books through Selfcheck Unit, the SIP2 is not sending the Item Identifier and Due Date, and because of this the Patrons are getting Item not checked out message. can you please look in to this. Parsing: 300NUN20180326 142806AAPSPHPS170013|AB104059|AJ|AH|AOMAIN|AFItem not checked out to SOUMITRA MIDYA|AY3AZE1C5 2018-03-26 14:27:44,123 INFO [ 7] MessageFormatter - Parsed: [30] Renew Response {ok = 0, renewal ok = False, magnetic media = null, desensitize = False, transaction date = 2018-03-26 14:28:06, [AA] patron identifier = #d587bf42, [AB] item identifier = "104059", [AJ] title identifier = "", [AH] due date = "", [AO] institution id = "MAIN", [AF] screen message = "Item not checked out to SOUMITRA MIDYA"} 2018-03-26 14:27:44,123 DEBUG [ 7] SipCirculationProvider - Duration of operation: 77 ms SIP Logs attached for your reference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21486] New: SIP does not return checked out (charged) items on patron_information request
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21486 Bug ID: 21486 Summary: SIP does not return checked out (charged) items on patron_information request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com You can test it with this: misc/sip_cli_emulator.pl -a localhost -p 6001 -su koha -sp koha -l CPL --patron 23529000126806 -s " Y " -m patron_information And see the "AU" field is empty: 64 00120181004 110729000000000001000000000000AOCPL|AA23529000126806|AEBrent Hopkins|BLY|CC5|AU|BD6692 Library Rd. Santa Cruz, CA 21234|BF(212) 555-1212|PB19771113|PCT|PIY|AFGreetings from Koha. | This is because commit bc001c2352fee419a2bbe20c0cf707afd9e5bd78 Bug 19935: Replace GetPendingIssues - SIP -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 16655] New: ERROR ON HOLIDAYS
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '19

05 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16655 Bug ID: 16655 Summary: ERROR ON HOLIDAYS Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: hblancoca(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Hi, I created holidays for vacation period, if i borrow a book on staff inferface have no problems,but if so the same over SIP2 protocol do no take the holidays defined. For example: humberto blanco can borrow book for 8 days. If checkout from staff interface in 2016-06-03 has no problem and the date_due take all my holidays (2016-07-25); but if I do the same process over 3m selfcheck machine the date_due is (2016-06-11) Really appreciate your help to solve this issue Humberto, -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 17826] New: Allow extended patron attributes to be sent in arbitrary SIP2 fields
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '19

03 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17826 Bug ID: 17826 Summary: Allow extended patron attributes to be sent in arbitrary SIP2 fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Some libraries need to be able to send additional patron data from the extended patron attributes in made up SIP2 fields for the patron information and patron status responses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 17768] New: spinelabel.css should be user editable.
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '19

02 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17768 Bug ID: 17768 Summary: spinelabel.css should be user editable. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The quick-label CSS file is currently part of the Koha distribution, stored at koha-tmpl/intranet-tmpl/prog/en/css/spinelabel.css. This means that users who use package Koha cannot change the styling of the quick slips without resorting to javascript. I would suggest that koha-tmpl/intranet-tmpl/prog/en/css/spinelabel.css be a default, but that we can change this via syspref. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 20720] New: Add sponsors to the about page
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '19

29 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20720 Bug ID: 20720 Summary: Add sponsors to the about page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org It would make sense to list the libraries sponsoring Koha developments on the about page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 16887] New: Entering a bad date in 'Koha out on loan' field sets items.onloan to 0000-00-00.
by bugzilla-daemon＠bugs.koha-community.org 28 Nov '19

28 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16887 Bug ID: 16887 Summary: Entering a bad date in 'Koha out on loan' field sets items.onloan to 0000-00-00. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To re-create 1/ Go to Circulation->Fast Cataloging 2/ Add a biblio record 3/ On Add Items screen, enter a space in 'Koha out on loan' (and enter item type of course). Save the item. 4/ items.onloan will be set to 0000-00-00. ... I'm not certain whether or not this is specific to the fast add framework. Note that this causes upstream issues with search -- any item that has items.onloan set to 0000-00-00 will cause an internal server error on the search results page, with the following error in plack.error.log: Can't locate object method "ymd" via package "dateonly" (perhaps you forgot to load "dateonly"?) at /usr/share/koha/li b/Koha/DateUtils.pm line 223. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 17526] New: OPAC lists require a sortfield
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '19

27 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17526 Bug ID: 17526 Summary: OPAC lists require a sortfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Using the OPAC, going into the public lists, I click one of them and get DBIx::Class::Storage::DBI::_dbh_execute(): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ASC LIMIT 10) `me` JOIN `biblio` `biblionumber` ON `biblionumber`.`biblionumber' THis is because the sortfield is empty and creates a SQL like GROUP BY ASC LIMIT 10. Missing the group by. In the intranet list, there's a default usage of 'title' that makes it all work. TESTING: 1) just create a public list with no sortfield. - virtualshelves.category = 2 - virtualshelves.sortfield = '' 2) click on the list in the OPAC's public list. Boom! -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 19819] New: C4::Context->dbh is unreasonably slow
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '19

27 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19819 Bug ID: 19819 Summary: C4::Context->dbh is unreasonably slow 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I have been profiling Koha the last day or so to try to fix some bottlenecks increasing performance of bulk-processing of data. Discovered that C4::Context->dbh was unexpectedly slow (Koha::Database->schema->storage->dbh is the culprit). If it is safe to do so, performance can be greatly improved by locally caching $dbh in a state variable. Patch will be provided shortly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20