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

[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 29939] New: Improve auth check in opac-ratings-ajax.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '22

14 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29939 Bug ID: 29939 Summary: Improve auth check in opac-ratings-ajax.pl 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org This script certainly needs a better authentication check but it is less trivial than the others. The block with Koha::Ratings calls should be within a check on loggedinuser. The whole script is a weird mix between an ajax script and a regular one. This statement will crash on an undefined borrowernumber (SQL constraint): Koha::Rating->new( { biblionumber => $biblionumber, borrowernumber => $loggedinuser, rating_value => $rating_value, })->store; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 30218] New: Add subfield g to 150 heading_fields
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '22

14 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30218 Bug ID: 30218 Summary: Add subfield g to 150 heading_fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org When creating authorities via SRU or linking exising authorities (via cgi-bin/koha/authorities/auth_finder.pl) the search results are generated using the hardcoded mappings $bib_heading_fields / $auth_heading_field from C4::Heading::MARC21. For TOPIC_TERM / field 150 these mappings currently include the subfield `abvxyz68`. But: We are using the GND provided by Deutsche Nationalbibliothek. We imported some authorities from there, for example: http://d-nb.info/gnd/4114171-4 "Kind <0-3 Jahre>" (kid 0-3 years) http://d-nb.info/gnd/4196417-2 "Kind <0-4 Jahre>" (kid 0-4 years) When searching for these terms, Koha only displays "Kind", which is not very helpful, as there are a lot of different authorities for different age bands. GND stores "Kind" in 150a, and "0-3 Jahre" in 150g. But in the hardcoded mappings used by Koha, subfield g is not included. This patch adds subfield g to these mappings, thus making it possible to easily select the correct authority. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[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 12 Oct '22

12 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

[Bug 28950] New: serialsUpdate cron does not mark an issue late until the next issue is expected
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '22

11 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28950 Bug ID: 28950 Summary: serialsUpdate cron does not mark an issue late until the next issue is expected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When running the cron it does this: 1 - Get all issues with a published date + grace period before today 2 - Loop the related subscriptions 3 - Check the next published date for the serial 4 - Compare the next issues publisheddate to today 5 - Mark late/generate the next issue if the next issue should already be published For a monthly serial with a 30 day grace period, this is usually ok For a yearly serial this is a problem 1 - Issue expected 2021-07-01, 30 day grace period 2 - As of 2021-08-01 that serial is past the grace period 3 - Next issue is planned for 2022-07-01 4 - Serial not marked late for a year -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 29778] New: Deleted additional_contents remain visible
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '22

11 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29778 Bug ID: 29778 Summary: Deleted additional_contents remain visible Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We have had 2 reports about this on the mailing list from 3 different people so far. It was not possible yet to determine the cause: https://lists.katipo.co.nz/pipermail/koha/2021-December/057161.html https://lists.katipo.co.nz/pipermail/koha/2021-December/057186.html I've tried to replicate on master, but no luck so far. -- You are receiving this mail because: You are watching all bug changes.

1 26