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

[Bug 18228] New: Working title
by bugzilla-daemon＠bugs.koha-community.org 29 Mar '18

29 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18228 Bug ID: 18228 Summary: Working title Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

1 63

[Bug 17941] New: CanBookBeRenewed is very inefficient/slow
by bugzilla-daemon＠bugs.koha-community.org 29 Mar '18

29 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17941 Bug ID: 17941 Summary: CanBookBeRenewed is very inefficient/slow Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: boutrosboutrosboutros(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I started investigating why populating the checkout list in the patron view sometimes took ages (minutes), and on occations even causing the system to almost halt because of DB overload. It turned out that reason is calls to C4::Circulation::CanBookBeRenewed. The critical factor is whether an item has many holds on it, and if there are many items that can fill the hold. Briefly looking at the code it seems obvious that the time spent grows exponentially with the number of holds and items. As one example, checking if an item with 111 holds (and 12 items on the biblio) can be renewed takes around 25 sec and generates over 18,000 SQL queries. I can't help to think there must be some missed "early returns" opportunities in the loops somewhere. For example, if there are more unfulfilled holds than available items, can the item ever be renewed? If no, return before even begin to calculate.. However, I know holds are full of complexities and things I probably haven't thought about so I need to dig into the code more. I would be very gratefull if anyone knowledgeable about this part of the code could help me find some ways to optimize this! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54

[Bug 20145] New: borrowers.datexpiry eq '0000-00-00' means expired?
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '18

28 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20145 Bug ID: 20145 Summary: borrowers.datexpiry eq '0000-00-00' means expired? Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org See bug http://lists.koha-community.org/pipermail/koha-devel/2018-February/044322.h… Koha::Patron->is_expired returns 0 if $self->dateexpiry eq '0000-00-00' And there is a test I wrote for it on bug 17578 (commit 5a0a2ce584dec74808f471b0f92b2114c3d6029e , GetMemberDetails - Remove is_expired) But then we also have, in C4::Circulation::CanBookBeIssued: 752 if ( !defined $patron->dateexpiry || $patron->dateexpiry eq '0000-00-00') { 753 $issuingimpossible{EXPIRED} = 1; 754 } else { With a test: is( $issuingimpossible->{EXPIRED}, 1, 'The patron should be considered as expired if dateexpiry is 0000-00-00' ); So, my questions, do you have a very old Koha installations to search if there is borrowers.is_expired == "0000-00-00" in it? Do you remember if it meant expired or not at some point? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 20045] New: Switch single-column templates to Bootstrap grid: Various
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20045 Bug ID: 20045 Summary: Switch single-column templates to Bootstrap grid: Various Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, josef.moravec(a)gmail.com, misilot(a)fit.edu, nengard(a)gmail.com, testopia(a)bugs.koha-community.org Blocks: 19980 This patch will convert several unrelated templates to use the Bootstrap grid: - about.tt - auth.tt - serials/subscription-add.tt - admin/admin-home.tt - reports/reports-home.tt - suggestion/suggestion.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19980 [Bug 19980] Omnibus: Update single-column templates to use Bootstrap grid -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 19468] New: Can't create basket in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19468 Bug ID: 19468 Summary: Can't create basket in acquisitions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 15685 When trying to create a new basket in acq, I get an internal server error: Can't call method "unblessed" on an undefined value at /home/vagrant/kohaclone/C4/Acquisition.pm line 829. I think this might be a side effect of the recently pushed bug 15685. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15685 [Bug 15685] Allow creation of items (AcqCreateItem) to be customizable per-basket -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 19695] New: Uncertain prices should not use find in list context
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19695 Bug ID: 19695 Summary: Uncertain prices should not use find in list context Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org When clicking on Uncertain prices button from a basket, the log fails with the following message: Cannot use "->find" in list context at <path>/acqui/uncertainprice.pl line 76. Similar to Bug 18179. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 20303] New: Receive order fails if no "authorised_by" value
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20303 Bug ID: 20303 Summary: Receive order fails if no "authorised_by" value Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bc(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org If there is no "authorised by" value on the order the "receive" option fails with 500 error. The file called is orderreceive.pl?ordernumber=1234&invoiceid=1234 orderreceive.pl should check if authorised_by exists before looking up patron information. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 20167] New: Item hold is set to bibliographic hold when changing pickup location
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20167 Bug ID: 20167 Summary: Item hold is set to bibliographic hold when changing pickup location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a patron has an item level hold with pickup location set to library A and staff then (via the Holds tab in the patron view) changes pickup location to library B, itemnumber is lost from the hold. This is a definite problem when the items within a bibliographic record are different things (separate volumes for example). This can be fixed by adding some code in Koha/REST/V1/Hold.pm This bit before the ModReserve call: if($hold->itemnumber()) { $params->{itemnumber} = $hold->itemnumber(); } However, given the FIXME comment in C4/Reserves.pm for ModReserve, I'm wondering if this is the desired fix: "Note that the forgoing can have the effect of causing item-level hold requests to turn into title-level requests. This will be fixed once reserves has separate columns for requested itemnumber and supplying itemnumber." A different method of solving this issue could be to provide itemnumber as part of the pickup-location-change call instead and keep the rest of the REST-API and ModReserve the way it works now. I'm somewhat unfamiliar with the how the Mojolicious system works, so I haven't looked into that method yet. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 20218] New: Tracklinks fails when URL has special characters
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20218 Bug ID: 20218 Summary: Tracklinks fails when URL has special characters 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Copy the url of a biblio in the opac 2 - Paste this into the 856$u ofd another record 3 - Enable anonymous link tracking 4 - View the second record in the opac 5 - Click the link 6 - Get a 404 error It seems on this line: if ( grep { /^$uri$/ } map { $_->{MARCURL} } @$marc_urls ) { The regex is reading the '?' in the uri as a special character and so the uri is not matched -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 19979] New: Search.t fails on facet info with one branch
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '18

27 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19979 Bug ID: 19979 Summary: Search.t fails on facet info with one branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 11