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

[Bug 14007] Item types for items hidden by OpacHiddenItems turn up in facet results
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '24

17 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 --- Comment #16 from Andreas Jonsson <andreas.jonsson(a)kreablo.se> --- Created attachment 164978 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164978&action=e… Bug 14007: Hide hidden itemtypes in opac facets. Test plan: * Start koha-testing-docker with elasticsearch or opensearch (e.g., ku-es7) * Make sure there is a built index for Elastic/OpenSearch: > koha-elasticsearch --reset --rebuild kohadev * Search for "book" in opac and note the facet values for itemtype * Change systempreference SearchEngine to ElasticSearch * Search for "book" in opac and note the facet values for itemtype * Go to the adminstration view of one of the itemtypes (for instance Visual Materials) and check "Hide in OPAC". * Search for "book" in opac and make sure the hidden itemtype do not appear as facet. * Search for "book" in staff interface and make sure the hidden itemtype still does appear as a facet. * Change back the systemprefence to Zebra * Search for "book" in opac and make sure the hidden itemtype do not appear as facet. * Search for "book" in staff interface and make sure the hidden itemtype still does appear as a facet. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14007] Item types for items hidden by OpacHiddenItems turn up in facet results
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '24

17 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 Andreas Jonsson <andreas.jonsson(a)kreablo.se> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Small patch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 21104] New: oai.pl returns wrong baseURL
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '24

17 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21104 Bug ID: 21104 Summary: oai.pl returns wrong baseURL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P4 Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 21102 Related/continuation of: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17785#c11 When using Plack Koha anwer a "cooler" (bug 18410) but invalid baseURL, /opac/oai.pl instead of given URI. As Tomas said on bug #17785: > Our fix for the XSLT masked the underlying bug (our code doesn't know > about the proxypass we do, and then Plack answers what he knows, > /opac/oai.pl). Originally deteced with official validator: https://www.openarchives.org/Register/ValidateSite Tested with: curl -s "baseURL?verb=Identify" | xpath -q -e "/OAI-PMH/Identify/baseURL" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21102 [Bug 21102] OAI-PMH specification conformance [UMBRELLA] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 35481] New: Ignore whitespace when entering or scanning barcodes in trusted web checkout modal
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35481 Bug ID: 35481 Summary: Ignore whitespace when entering or scanning barcodes in trusted web checkout modal 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 30979 Like in other barcode fields we should ignore leading and trailing whitespace when entering barcodes for the new trusted self checkout feature. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30979 [Bug 30979] Add ability for OPAC users to checkout to themselves -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 35482] New: Trusted self check modal too small for translations
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35482 Bug ID: 35482 Summary: Trusted self check modal too small for translations 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 30979 The modal for the trusted self checkout is quite small, but that doesn't work so well for languages with longer words (yes, German...). It would be nice if we made it slightly bigger to accomodate for variations like this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30979 [Bug 30979] Add ability for OPAC users to checkout to themselves -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 32711] New: Add biblio details to trusted self-checkout modal
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32711 Bug ID: 32711 Summary: Add biblio details to trusted self-checkout modal 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We should add further biblio details to the summary table that appears in the OPAC trusted self-checkout modal feature. Title and callnumber for example -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 35805] New: Two issues with HoldsQueue::MapItemsToHoldRequests
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35805 Bug ID: 35805 Summary: Two issues with HoldsQueue::MapItemsToHoldRequests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com 1. This clause from the below if statement must be incorrect: ( !$request->{itemtype} # If hold itemtype is set, item's itemtype must match || ( $request->{itemnumber} && ( $items_by_itemnumber{ $request->{itemnumber} }->{itype} eq $request->{itemtype} ) ) ) Because $request->{itemnumber} is guaranteed to be undefined due to this clause: next if defined($request->{itemnumber}); # already handled these The clause was probably ment to be this: ( !$request->{itemtype} || ( $items_by_itemnumber{ $item->{itemnumber} }->{itype} eq $request->{itemtype} ) ) foreach my $request (@$hold_requests) { last if $num_items_remaining == 0; next if $request->{allocated}; next if defined($request->{itemnumber}); # already handled these # look for local match first my $pickup_branch = $request->{branchcode} || $request->{borrowerbranch}; my ($itemnumber, $holdingbranch); my $holding_branch_items = $items_by_branch{$pickup_branch}; my $priority_branch = C4::Context->preference('HoldsQueuePrioritizeBranch') // 'homebranch'; if ( $holding_branch_items ) { foreach my $item (@$holding_branch_items) { next unless $items_by_itemnumber{ $item->{itemnumber} }->{_object}->can_be_transferred( { to => $libraries->{ $request->{branchcode} } } ); if ( $request->{borrowerbranch} eq $item->{$priority_branch} && _checkHoldPolicy($item, $request) # Don't fill item level holds that contravene the hold pickup policy at this time && ( !$request->{itemtype} # If hold itemtype is set, item's itemtype must match || ( $request->{itemnumber} && ( $items_by_itemnumber{ $request->{itemnumber} }->{itype} eq $request->{itemtype} ) ) ) && ( !$request->{item_group_id} # If hold item_group is set, item's item_group must match || ( $item->{_object}->item_group && $item->{_object}->item_group->id eq $request->{item_group_id} ) ) ) { $itemnumber = $item->{itemnumber}; last; } } $holdingbranch = $pickup_branch; 2. Then the code continues: } elsif ($transport_cost_matrix) { But surely this should be: } if (!defined $itemnumber && defined $transport_cost_matrix) { Because the important condition here is that we failed to allocate from the local holding branch. Surely the transport_cost_matrix should still be used just even if we tried allocating locally first, but failed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 14322] Can't link to an item search
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14322 Brendan Lawlor <blawlor(a)clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor(a)clamsnet.org --- Comment #4 from Brendan Lawlor <blawlor(a)clamsnet.org> --- Posting this patch for feedback. itemsearch.pl overrides the form submit button and gets an array of objects for all the parameters. This patch uses the same code that processes the form inputs into an array of objects, which is used in the ajax call to update the #results dataTable. It takes that array of parameters and uses jquery to parameterize it into a url encoded string. I think the remaining changes should be pretty minimal the encoded url is just a different way of representing the same data it already processes with the ajax call. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14322] Can't link to an item search
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14322 Michelle Spinney <mspinney(a)clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mspinney(a)clamsnet.org | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14322] Can't link to an item search
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '24

16 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14322 --- Comment #3 from Brendan Lawlor <blawlor(a)clamsnet.org> --- Created attachment 164962 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164962&action=e… Bug 14322: Add button to copy link to an item search This work in progress patch adds a button to copy a url with all the parameters for an item search. The button currently works to copy a url with all the item search parameters url encoded, but the url returns 500.To make it work itemsearch.pl needs some updates to handle when the url parameter shareable=1, then it should process all the prameters from the url. Test plan: 1. Apply patch 2. Do an item search 3. On the results page see a new 'Copy shareable link' button 4. Click the button and confirm that you can paste a url with all parameters from the form url encoded 5. Paste the url in the browser and notice you get a 500 error :( -- You are receiving this mail because: You are watching all bug changes.

1 0