December 2023 - Koha-bugs - lists.koha-community.org

[Bug 22103] New: ILL: Tests for migrate
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22103 Bug ID: 22103 Summary: ILL: Tests for migrate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Target Milestone: --- We decided to PQA on bug 20640 so that QA could continue on the ILL tree.. but, I spotted right at the last moment that I've managed to miss the tests somehow.. I'll be submitting them here shortly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 33423] New: Cypress - Using UI to login is against best practice
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33423 Bug ID: 33423 Summary: Cypress - Using UI to login is against best practice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32030 https://docs.cypress.io/guides/references/best-practices#Organizing-Tests-L… We should update the way we login in for our cypress tests using the logging in recipes in the above link (if possible?), and not login through UI, as we are at the moment. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 30362] New: GetSoonestRenewDate is technically wrong when NoRenewalBeforePrecision set to date soonest renewal is today
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30362 Bug ID: 30362 Summary: GetSoonestRenewDate is technically wrong when NoRenewalBeforePrecision set to date soonest renewal is today Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial 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 In the code: 3309 if ( C4::Context->preference('NoRenewalBeforePrecision') eq 'date' 3310 and $issuing_rule->{lengthunit} eq 'days' ) 3311 { 3312 $soonestrenewal->truncate( to => 'day' ); 3313 } 3314 return $soonestrenewal if $now < $soonestrenewal; We truncate soonest renewal, so when it matches todays date line 3314 compares Today at 00:00:00 to Today at (time renewal checked) So we don't return soonest renewal, but fall back to $now - which does allow renewal, but is not technically correct -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 16117] New: Feature request: Log borrower cardnumbers and item barcodes which are not valid
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16117 Bug ID: 16117 Summary: Feature request: Log borrower cardnumbers and item barcodes which are not valid Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com On any circ screen where a barcode could be scanned (circ.pl, checkin.pl, checkout and return boxes), we should have the option of logging failed barcode scans, for the purpose of trouble-shooting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 17337] New: waitingreserves.pl should trigger transfers as well as holds
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '24

11 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17337 Bug ID: 17337 Summary: waitingreserves.pl should trigger transfers as well as holds Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 17010 addresses triggering the next hold when a hold is cancelled, but transfers should also be triggered. Currently in 3.22.8 nothing happens. It is unclear if 17010 addresses transfers as well. Also, in 3.18 local holds were spotty when holds were triggered. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 35407] New: Terminology: Show fewer collection codes
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35407 Bug ID: 35407 Summary: Terminology: Show fewer collection codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Collection codes should be collection. We don't show codes. koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-facets.inc:49 Text for item types should also be verified. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 35323] New: Terminology: Add additional elements to the "More Searches" bar...
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35323 Bug ID: 35323 Summary: Terminology: Add additional elements to the "More Searches" bar... Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found in translation: Add additional elements to the "More Searches" bar on the OPAC, with this content (leave blank to disable). I don't think the element is labelled "More searches" anywhere in Koha - maybe we should call it "Navigation links below the simple search" or similar? Also: capitalization. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 35461] New: Renew All 66 SIP server response messages produce HASH content in replies
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35461 Bug ID: 35461 Summary: Renew All 66 SIP server response messages produce HASH content in replies Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org "Renew All" -function aka. 65-66-messages work like this: 66-return messages has renewed items in BM-fields and non-renewables go into BN-fields. If all items were renewable, then the reply message looks like: Reply: 13.07.2022 10:06:17:530 OUTESTI1 6610005000020220713 100616AOOUPK|BM564N15977171|BM564N09203960|BM564N23261720|BM564N25161958|BM564N23455012|C4::SIP::SIPServer=HASHC4::SIP::SIPServer=HASHAY6AZCEFE If items include renewables and non-renewables, the response includes the renewed items first, then a HASH mixed into the first BN-field, then rest of the renewed ones like they should show in BN-fields and after that, anohter HASH: 13.07.2022 14:41:32:610 OUTESTI1 6610003000420220713 144130AOOUPK|BM564N23455012|BM564N23261720|BM564N25161958|C4::SIP::SIPServer=HASHBN564N09203960|BN564N04191259|BN564N15977171|BN564N13788332|C4::SIP::SIPServer=HASHAY8AZC7C5 If all loans were unrenewable (this test included just one item), you first get a HASH in a BN-field, and another at the end. 13.07.2022 14:49:00:037 OUTESTI1 6610000000120220713 144858AOOUPK|C4::SIP::SIPServer=HASHBN564N19874533|C4::SIP::SIPServer=HASHAY9AZDD3B Our self checkout/checkin machine can handle/parse these reply messages correctly, but this might not be the case with all self checkout/checkin devices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 32593] New: Item search option location breaks with only one location defined
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32593 Bug ID: 32593 Summary: Item search option location breaks with only one location defined Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When there is only one location (LOC) configured, the search option for locations on item search is not generated correctly. It shows the 'all locations' option and then 3 empty (no description) entries: <select id="location" name="location" multiple="multiple" size="4"> <option value="" selected="selected"> <span>All locations</span> </option> <option value="REF"></option> <option value="Reference"></option> <option value="Reference"></option> </select> As soon as a second location is configured, the list will be generated correctly. To test: * delete all LOC entried, but one, I left REF in the sandbox * Go to item search * Verify that only 'all locations displays' with 3 clickable empty entries below * Add another LOC entry * Verify the list now works again -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33842] New: Search for authid not returning right results with QueryAutoTruncate ON
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33842 Bug ID: 33842 Summary: Search for authid not returning right results with QueryAutoTruncate ON Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es Conditions to replicate this bug: 1) Preference QueryAutoTruncate activated 2) Have authorities with low authids 3) ElasticSearch, though it should also happen with Zebra. You can try it on this demo, it's on the master branch. Intranet: https://intranet.koha-community.es OPAC: https://catalog.koha-community.es/ User demo/demo The following searchs return different results: 1) Search in the catalog an:1 The QueryAutoTruncate adds * so it returns all the biblios that use authorities with authids that begin with 1, which are 81. That doesn't make sense as those authorities have nothing in common. https://intranet.koha-community.es/cgi-bin/koha/catalogue/search.pl?q=an%3A1 2) The authority with the id 1 is Mika Ninagawa, if you search her in the Authorities module, it says the authority is being used in two records, which is correct. https://intranet.koha-community.es/cgi-bin/koha/authorities/authorities-hom… 3) In the authority detail, Koha makes the same query as in point 1 so it appears it's being used in 81 records. https://intranet.koha-community.es/cgi-bin/koha/authorities/detail.pl?authi… I think this disparity in results can be confusing for librarians and readers, as they won't understand why Koha is recovering records that are unrelated to the author/subject... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6