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

[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

[Bug 29975] New: (Bug 21729 followup) patron_expiration_date missing in API
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29975 Bug ID: 29975 Summary: (Bug 21729 followup) patron_expiration_date missing in API 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: fridolin.somers(a)biblibre.com CC: tomascohen(a)gmail.com Bug 21729 added to holds table the column patron_expiration_date. This must impact the REST API. Currently test suite is failing : https://jenkins.koha-community.org/view/master/job/Koha_Master_D10/516/test… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 28287] New: reports execution should stop on execute_query errors
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28287 Bug ID: 28287 Summary: reports execution should stop on execute_query errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org nbe_rows is computed even if execute_query return an error. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 28804] New: 500 Error when running report with bad syntax
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28804 Bug ID: 28804 Summary: 500 Error when running report with bad syntax Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jstallings(a)tsas.org QA Contact: testopia(a)bugs.koha-community.org In previous versions, running an SQL report with an error (typo, bad syntax) would yield an error page with the problem syntax highlighted. 21.05 returns only a 500 error. Excerpt from plack-intranet-error.log here: https://pastebin.com/0UCYkU46 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 20627] New: Prevent leakages of user permissions to api access tokens
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20627 Bug ID: 20627 Summary: Prevent leakages of user permissions to api access tokens Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, dpavlin(a)rot13.org, julian.maurice(a)biblibre.com, katrin.fischer(a)bsz-bw.de, oleonard(a)myacpl.org, tomascohen(a)gmail.com Depends on: 20568 Blocks: 20612, 20624 Bug #20568 allow users to create API access tokens, but it always associates all a users permissions with that access token and additionally if that user comes to have more permissions down the line those additional permissions are automagically added to the access token as well. This is generally bad practice for access tokens as in general, they should be of a definite scope and any time additional privileges are required the client application should have to ask for them and receive a new token with the additional privileges assigned to it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20568 [Bug 20568] Add API key management interface for patrons https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20612 [Bug 20612] Make OAuth2 use patron's client_id/secret pairs https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20624 [Bug 20624] Allow switching off the OAuth2 client credentials grant -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13