October 2021 - Koha-bugs - lists.koha-community.org

[Bug 29150] New: hold pickup sent two patrons
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '22

18 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29150 Bug ID: 29150 Summary: hold pickup sent two patrons Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: amy(a)bywatersolutions.com 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 watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29374] New: searchResults explodes if biblio record has been deleted
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '22

18 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29374 Bug ID: 29374 Summary: searchResults explodes if biblio record has been deleted Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Searching Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org >From commit 1ad0e172cddce560afcc23579948d0c4a1eca71c Bug 3142: Use filter_by_for_holds where holdability is calculated + $can_place_holds = $biblio_object->items->filter_by_for_hold()->count; This is exploding early in C4::Search::searchResults if the record is indexed but deleted from the DB. Can't call method "items" on an undefined value at /kohadevbox/koha/C4/Search.pm line 2000 C4::Search::searchResults('HASH(0x55dc9a4076c0)', 'kw,wrdl: d', 432, 20, 0, undef, 'ARRAY(0x55dc9a3757e8)', 'HASH(0x55dc99f94a50)') called at /kohadevbox/koha/opac/opac-search.pl line 613 -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 28824] New: Errant variable declaration in C4::Letters
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '22

17 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28824 Bug ID: 28824 Summary: Errant variable declaration in C4::Letters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The fix for bug 26935 actually broke the feature introduced with bug 21898... The fix is simple, drop the 'my'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 22760] New: cataloging search yields no results if queryparser is on
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '22

17 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22760 Bug ID: 22760 Summary: cataloging search yields no results if queryparser is on Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mikael.olangcay-brisebois(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If QueryParser is on and defaultsortorder is set to relevance,dsc, when you do a cataloging search, first page yields results but other pages don't return any results half the time. It also seems to break the sort by popularity, but that is not adressed by this patch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 22407] New: OMNIBUS: Use DBIC relations to fetch related object rather than searching for the object
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '22

14 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22407 Bug ID: 22407 Summary: OMNIBUS: Use DBIC relations to fetch related object rather than searching for the object 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Example, instead of this: return Koha::Patrons->find( $self->guarantorid() ); We should do this: return Koha::Patron->_new_from_dbic($self->_result->guarantor); This allows us to use prefetch and perform a single query as opposed to multiple queries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 26995] New: Drop column relationship from borrower tables
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26995 Bug ID: 26995 Summary: Drop column relationship from borrower tables 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 14570 added a borrower_relationships table but it didn't remove the relationship column from the following tables: - deletedborrowers - borrowers - borrower_modifications It will need to be removed from many of the same places as "guarantorid" from Bug 14570 like: - C4/Auth_with_ldap - C4/SIP/ILS/Patron.pm - Possibly other places... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 28543] New: Clicking on 'New record' will use default framework
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28543 Bug ID: 28543 Summary: Clicking on 'New record' will use default framework Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In biblio records cataloguing, clicking on 'New from z39.50/SRU' will run action with default framework. Clicking on 'New record' sould do the same. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 28372] New: Use variables for 007 controlfield translations in MARC21slim2intranetResults.xsl
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28372 Bug ID: 28372 Summary: Use variables for 007 controlfield translations in MARC21slim2intranetResults.xsl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Slight performance improvement over fetching the same field every time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 27463] New: OAI-PMH date handling in ListBase.pm
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27463 Bug ID: 27463 Summary: OAI-PMH date handling in ListBase.pm Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: rudolfbyker(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently in Koha/OAI/Server/ListBase.pm two different criteria are used for querying dates and displaying dates. When displaying the "Last Modified" date, this is used: SELECT MAX(timestamp) FROM ( SELECT timestamp FROM biblio_metadata WHERE biblionumber = ? UNION SELECT timestamp FROM deleteditems WHERE biblionumber = ? UNION SELECT timestamp FROM items WHERE biblionumber = ? ) bi But when querying, only biblio_metadata.timestamp is used. This should be made consistent. We could use a query like this (using a join, but removing the need to do a separate query for each record, so it might actually be faster than what we have now): select bm.biblionumber, greatest(bm.timestamp, i.timestamp) as t from biblio_metadata bm inner join items i on bm.biblionumber=i.biblionumber having t >= '2020-07-14' and t <= '2020-07-15' limit 10; Furthermore, we should only use items.timestamp and deleteditems.timestamp when the user has the "include_items" option set in their OAI-PMH config. It does not make sense to query item timestamps if you are only sending data about the records, and not the items. Therefore, if "include_items" is disabled, we can do a simpler query: select biblionumber, timestamp from biblio_metadata where timestamp >= '2020-07-14' and timestamp <= '2020-07-15' limit 10; See full discussion on IRC: http://irc.koha-community.org/koha/2021-01-18#i_2324076 Definition of "datestamp" for reference: https://www.openarchives.org/OAI/openarchivesprotocol.html#Datestamp -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 19064] New: OAI-PMH Records appearing in OAI that can' t be found in OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19064 Bug ID: 19064 Summary: OAI-PMH Records appearing in OAI that can't be found in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: marrone.patricio(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hello, While harvesting Koha records from the OAI-PMH interface, I found a series of records that can't be accessed using the OPAC interface. That is, the harvester finds a record with an identifier, say http://example.com/cgi-bin/koha/oai.pl?verb=GetRecord&metadataPrefix=oai_dc… that shows the complete record. Trying to link to the OPAC using the biblionumber in the last part of the identifier, say http://example.com/cgi-bin/koha/opac-detail.pl?biblionumber=572 I get a 404 error. I have yet to confirm this, but this might be related to the records being hidden in the OPAC view being leaked into OAI. In that case, I would expect the record to have a deleted status in OAI so that in can be removed from the harvesting results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2