As of now, if I go on the OPAC to place a hold, I'm presented a list of available pickup locations for that biblio. However, If I click on "more options" and select a specific item with limited transfers, I can still select any pickup location available for the biblio. This leads to a user being able to select a pickup location and be denied the hold request only after confirmation, and then have to restart again (without knowing which libraries will work). I think that can lead to some frustration for users. This is quite similar to BZ33302 or BZ10993 but I will provide a new patch with the use of Koha's api and make the OPAC more similar to the intranet interface.
Created attachment 192461 [details] [review] Bug 41768: item-level holds on OPAC will provides valid pickup locations 1) Enforce library transfer limits (UseBranchTransferLimits) 2) In administration > branch transfer rules: disallow transfer from Centerville to any other library for everything 3) Search for a record with at least one item in Centerville in staff 4) Try to place an item level hold on a Centerville item. For the Centerville item, only Centerville should be presented as possible pickup-location 5) Switch to the OPAC 6) Try to place an item level hold there on the Centerville item, for pick-up at Fairview. 7) Confirm, you will get an error because item cannot be transfered to Fairview. 8) Apply patch and repeat step 6. 9) If you check Centerville's items, the pickup location selector should only show Centerville. 10) If you check "next available item" or any item not from Centerville, you should get any library. Sponsored-by BibLibre
QA scripts not happy with lib/select2 images, dunno how to fix this, anyone? <code> Result: [PASS] koha-tmpl/opac-tmpl/bootstrap/en/includes/select2.inc [PASS] koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-reserve.tt [PASS] koha-tmpl/opac-tmpl/bootstrap/js/pickup-locations.js [FAIL] koha-tmpl/opac-tmpl/lib/select2/css/select2-spinner.gif FAIL new_line_at_the_end_of_file Missing new line at the end of file, make sure your editor correctly reads .editorconfig ('insert_final_newline = true'). See bug 40541. [PASS] koha-tmpl/opac-tmpl/lib/select2/css/select2.min.css [FAIL] koha-tmpl/opac-tmpl/lib/select2/css/select2.png FAIL new_line_at_the_end_of_file Missing new line at the end of file, make sure your editor correctly reads .editorconfig ('insert_final_newline = true'). See bug 40541. [FAIL] koha-tmpl/opac-tmpl/lib/select2/css/select2x2.png FAIL new_line_at_the_end_of_file Missing new line at the end of file, make sure your editor correctly reads .editorconfig ('insert_final_newline = true'). See bug 40541. [FAIL] koha-tmpl/opac-tmpl/lib/select2/js/select2.min.js FAIL new_line_at_the_end_of_file Missing new line at the end of file, make sure your editor correctly reads .editorconfig ('insert_final_newline = true'). See bug 40541. [PASS] opac/opac-reserve.pl Processing additional checks PASS! </code>
Ah, also I moved the pickup location selector below the item selection box. I think it make more sense this way since we want to select a pickup location after we select which item we want to place a hold for.
Just realized I was testing with the "koha" user on ktd which has superlibrarian permissions, which includes the necessary permission for : Get valid pickup locations for an item koha-authorization: {"permissions":{"reserveforothers":"place_holds"}} If I test with an OPAC user it doesn't work because the API requests gets a 403. We probably need a public API route to get available pickup locations for an item+patron combination without that librarian permission, I'll submit a patch for that. Putting the bug back in "Assigned" status.
Created attachment 192549 [details] [review] Bug 41768: make pickup_locations endpoints public Sponsored-by BibLibre
Created attachment 192550 [details] [review] Bug 41768: update js to use public routes Sponsored-by BibLibre
Created attachment 192551 [details] [review] Bug 41768: update tests Sponsored-by BibLibre
Hmm the OPAC does need to use /public endpoints, but I don't know about the staff interface using /public endpoints. But then should there be duplicate endpoints across the interfaces? (It's a shame we have /public endpoints rather than /admin endpoints as that would make the distinction clearer.)