[Bug 41768] New: OPAC pickup location selector doesn't reflect available pickup location if you select a specific item
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Bug ID: 41768 Summary: OPAC pickup location selector doesn't reflect available pickup location if you select a specific item Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard@myacpl.org Reporter: arthur.suzuki@biblibre.com QA Contact: testopia@bugs.koha-community.org 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #1 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 192461 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192461&action=edit 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #2 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- 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> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33302 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=10993 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #3 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clemens.tubach@kit.edu, | |katrin.fischer@bsz-bw.de, | |michaela.sieber@kit.edu -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |arthur.suzuki@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|arthur.suzuki@biblibre.com |oleonard@myacpl.org Status|Needs Signoff |ASSIGNED --- Comment #4 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #5 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 192549 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192549&action=edit Bug 41768: make pickup_locations endpoints public Sponsored-by BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #6 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 192550 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192550&action=edit Bug 41768: update js to use public routes Sponsored-by BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #7 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 192551 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192551&action=edit Bug 41768: update tests Sponsored-by BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31982 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- 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.) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #9 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (In reply to David Cook from comment #8)
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.)
I don't think staff interface should need a specific "admin" endpoint when a "public" endpoint does the job and serve the purpose. And I think this "pickup_locations" endpoint should definitely be public rather than private! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #9)
(In reply to David Cook from comment #8)
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.)
I don't think staff interface should need a specific "admin" endpoint when a "public" endpoint does the job and serve the purpose. And I think this "pickup_locations" endpoint should definitely be public rather than private!
I think that you're misunderstanding what I'm saying. I probably wasn't clear enough. What I meant was that most of our endpoints are "/admin" endpoints but we don't label them like that. Instead, we labelled normal endpoints as "/public". -- At some point, we might need to look at changing/removing the system preferences RESTPublicAnonymousRequests and RESTPublicAPI which can be used to cripple the OPAC which uses the /api/v1/public endpoints... If you did use that /public endpoint and someone had RESTPublicAPI set to disable, then holds wouldn't work anymore in the staff interface, right? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #11 from Arthur Suzuki <arthur.suzuki@biblibre.com> ---
I think that you're misunderstanding what I'm saying. I probably wasn't clear enough.
What I meant was that most of our endpoints are "/admin" endpoints but we don't label them like that.
Instead, we labelled normal endpoints as "/public".
I think I get it, you're totally right, public endpoints should be the default (and probably enabled by default)
At some point, we might need to look at changing/removing the system preferences RESTPublicAnonymousRequests and RESTPublicAPI which can be used to cripple the OPAC which uses the /api/v1/public endpoints...
If you did use that /public endpoint and someone had RESTPublicAPI set to disable, then holds wouldn't work anymore in the staff interface, right?
gosh you're right. but I think that's not the only part of koha like this, the holdings table on opac-details page also make use of the public API afaik. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #12 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- <pre> arthur@bibook:~/repos/koha$ grep -r 'api/v1/' koha-tmpl/opac-tmpl/ koha-tmpl/opac-tmpl/bootstrap/js/ratings.js: fetch("/api/v1/public/biblios/"+biblionumber+"/ratings", { koha-tmpl/opac-tmpl/bootstrap/js/modals/checkout.js: url: "/api/v1/public/items?_match=exact&external_id=" + external_id, koha-tmpl/opac-tmpl/bootstrap/js/modals/checkout.js: url: '/api/v1/public/checkouts/availability?item_id=' + item_id + '&patron_id=' + logged_in_user_id, koha-tmpl/opac-tmpl/bootstrap/js/modals/checkout.js: url: '/api/v1/public/patrons/'+logged_in_user_id+'/checkouts', koha-tmpl/opac-tmpl/bootstrap/js/modals/checkout.js: url: '/api/v1/public/patrons/' koha-tmpl/opac-tmpl/bootstrap/js/modals/catalog_concern.js: url: '/api/v1/public/tickets', koha-tmpl/opac-tmpl/bootstrap/js/pickup-locations.js: "/api/v1/public/biblios/" + koha-tmpl/opac-tmpl/bootstrap/js/pickup-locations.js: "/api/v1/public/items/" + koha-tmpl/opac-tmpl/bootstrap/js/pickup-locations.js: "/api/v1/public/holds/" + koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-user.tt: url: '/api/v1/public/patrons/'+borrowernumber+'/article_requests/'+article_request_id+'?cancellation_reason=OPAC', koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-memberentry.tt: url: "/api/v1/public/patrons/[% logged_in_user.borrowernumber | uri %]/guarantors/can_see_checkouts", koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-memberentry.tt: url: "/api/v1/public/patrons/[% logged_in_user.borrowernumber | uri %]/guarantors/can_see_charges", koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt: url: "/api/v1/public/libraries/" + branchcode, </pre> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #11)
gosh you're right. but I think that's not the only part of koha like this, the holdings table on opac-details page also make use of the public API afaik.
Yep. That's why my earlier frustration about labelling and how the API gets used hehe. That said, note that so far public API endpoints are only used in OPAC. They're not used in the staff interface. I think this one needs to be discussed with other devs. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #14 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (In reply to David Cook from comment #13)
That said, note that so far public API endpoints are only used in OPAC. They're not used in the staff interface. I think this one needs to be discussed with other devs.
well, given the public endpoints are used in the OPAC I'd say they are quite mandatory. That being said, I don't see any good reason why the staff interface should not use a public endpoint. Why would we want to duplicate an endpoint with the same results/data? (imo, we should not duplicate, that leads to confusion) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #14)
(In reply to David Cook from comment #13)
That said, note that so far public API endpoints are only used in OPAC. They're not used in the staff interface. I think this one needs to be discussed with other devs.
well, given the public endpoints are used in the OPAC I'd say they are quite mandatory.
Yep, I would agree with you there. Hence my comment about those 2 system preferences being a problem.
That being said, I don't see any good reason why the staff interface should not use a public endpoint.
Yeah, you might have a point. I'm working on a different bug where someone added a public endpoint to be used for both the staff interface and the OPAC. I'm not sure what I think of it yet. On one hand, having admin and /public endpoints separate allows for a clear separation of concerns. On the other hand, if the endpoint is going to be used exactly the same in both interfaces, then surely it would make sense to just have one endpoint. That being said, I thought pickup locations were scoped to individual users. Indeed if you look at Koha/REST/V1/Biblios.pm you can see that it takes a patron_id and public endpoints shouldn't allow people to provide a patron_id. It would need to take the logged in user's patron_id. So it would need to be a different endpoint.
Why would we want to duplicate an endpoint with the same results/data? (imo, we should not duplicate, that leads to confusion)
You mean like the following? /api/v1/public/libraries/{library_id} /api/v1/libraries/{library_id} /api/v1/public/items /api/v1/items /api/v1/public/oauth/login/{provider_code}/{interface} /api/v1/oauth/login/{provider_code}/{interface} -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #16 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (In reply to David Cook from comment #15)
(In reply to Arthur Suzuki from comment #14) Yeah, you might have a point. I'm working on a different bug where someone added a public endpoint to be used for both the staff interface and the OPAC. I'm not sure what I think of it yet.
Can you give me the bug number?
That being said, I thought pickup locations were scoped to individual users. Indeed if you look at Koha/REST/V1/Biblios.pm you can see that it takes a patron_id and public endpoints shouldn't allow people to provide a patron_id. It would need to take the logged in user's patron_id.
Yes, it needs the patron ID, but is that really a problem? it's not like the output/reply gives any personal data about the patron so, in that specific use-case is that a problem?
You mean like the following? /api/v1/public/libraries/{library_id} /api/v1/libraries/{library_id}
/api/v1/public/items /api/v1/items
/api/v1/public/oauth/login/{provider_code}/{interface} /api/v1/oauth/login/{provider_code}/{interface}
Yes, I know that already exists but why? could be only the public endpoint imo -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |arthur.suzuki@biblibre.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #17 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- I have a proposal to make, what if I rework this patch set to add the public route for pickup_locations rather than replace the private one? That would make this patch work without making too much changes to the API. And maybe we can think of a broader rework of the api in that other bug31982 ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #16)
(In reply to David Cook from comment #15)
(In reply to Arthur Suzuki from comment #14) Yeah, you might have a point. I'm working on a different bug where someone added a public endpoint to be used for both the staff interface and the OPAC. I'm not sure what I think of it yet.
Can you give me the bug number?
I can't at present.
That being said, I thought pickup locations were scoped to individual users. Indeed if you look at Koha/REST/V1/Biblios.pm you can see that it takes a patron_id and public endpoints shouldn't allow people to provide a patron_id. It would need to take the logged in user's patron_id.
Yes, it needs the patron ID, but is that really a problem? it's not like the output/reply gives any personal data about the patron so, in that specific use-case is that a problem?
Yes, it's a problem, because you're allowing an unauthorised action against a different patron. Even if the impact is considered trivial, it's still an unauthorised release of information. It's a problem.
You mean like the following? /api/v1/public/libraries/{library_id} /api/v1/libraries/{library_id}
/api/v1/public/items /api/v1/items
/api/v1/public/oauth/login/{provider_code}/{interface} /api/v1/oauth/login/{provider_code}/{interface}
Yes, I know that already exists but why? could be only the public endpoint imo
I know you think that but I disagree. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #17)
I have a proposal to make, what if I rework this patch set to add the public route for pickup_locations rather than replace the private one? That would make this patch work without making too much changes to the API. And maybe we can think of a broader rework of the api in that other bug31982 ?
I'm not sure I understand what you're saying here. If you're saying you're going to leave the current private pickup_locations endpoint and instead make a new public endpoint, then I agree. Just make sure it's scoped to the logged in user and it's all good. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192549|0 |1 is obsolete| | Attachment #192550|0 |1 is obsolete| | Attachment #192551|0 |1 is obsolete| | --- Comment #20 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 193334 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193334&action=edit Bug 41768: create and use public pickup_locations endpoints Sponsored-by: BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #21 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (In reply to David Cook from comment #19)
(In reply to Arthur Suzuki from comment #17)
I have a proposal to make, what if I rework this patch set to add the public route for pickup_locations rather than replace the private one? That would make this patch work without making too much changes to the API. And maybe we can think of a broader rework of the api in that other bug31982 ?
I'm not sure I understand what you're saying here.
If you're saying you're going to leave the current private pickup_locations endpoint and instead make a new public endpoint, then I agree. Just make sure it's scoped to the logged in user and it's all good.
Hi David, I've replaced my previous patches with a new one which adds public endpoints rather than replace the private ones. Also I've removed the patron_id parameter on the public endpoint and made the changes so that if that parameter is missing it will fetch the available pickup locations for the connected user. Best, Arthur -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #22 from David Cook <dcook@prosentient.com.au> --- Thanks for doing that, Arthur. I notice though that you're not checking "$c->stash('is_public')". That would be the way to wrap the public endpoint functionality. The way to get the user is $c->stash('koha.user'), although that reminds me that while this endpoint would work for the OPAC, it won't work so well for third-parties with system users, but I suppose those third-parties would need to rely on non-public/admin endpoints anyway. One day we'll fix the API... The Holds.pm should also check that the hold_id sent belongs to the user. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #23 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Ok, I will work further on that and apply your advices, thanks for the hints! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #193334|0 |1 is obsolete| | --- Comment #24 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 193337 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193337&action=edit Bug 41768: create and use public pickup_locations endpoints Sponsored-by: BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff --- Comment #25 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #23)
Ok, I will work further on that and apply your advices, thanks for the hints!
Thanks for that. I'll have to take a look a bit later. Running behind today. Could you remember to put this to "Needs Signoff" rather than "Signed Off" though as no one has signed it off yet. I'll switch it for you now. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #26 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (In reply to David Cook from comment #25)
(In reply to Arthur Suzuki from comment #23)
Ok, I will work further on that and apply your advices, thanks for the hints!
Thanks for that. I'll have to take a look a bit later. Running behind today.
Could you remember to put this to "Needs Signoff" rather than "Signed Off" though as no one has signed it off yet. I'll switch it for you now.
yup, don't try it right now yet, I have to solve that as well :
The way to get the user is $c->stash('koha.user')
(just realizing I forgot that part). Next patch will be fine. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #193337|0 |1 is obsolete| | --- Comment #27 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 193373 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193373&action=edit Bug 41768: create and use public pickup_locations endpoints Sponsored-by: BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #28 from David Cook <dcook@prosentient.com.au> --- I find the code in Koha/REST/V1/Biblios.pm looks weird. Like it shouldn't default to koha.user in the private endpoint, but technically since patron_id is required for it, it will always reset it, so technically it should be fine... but it looks potentially confusing and it could impact long-term maintainability. Not a blocker I guess but I don't like it. Why add "use C4::Context" to Koha/REST/V1/Holds.pm and Koha/REST/V1/Items.pm? Otherwise... I think it's looking all right. I'll give it a test. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #29 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #1) The test plan is missing a step for rebuilding the API and restarting Koha. Without that step, the change won't work correctly.
1) Enforce library transfer limits (UseBranchTransferLimits) 2) In administration > branch transfer rules: disallow transfer from Centerville to any other library for everything
I think you meant "Library transfer limits"
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.
This looks good -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #30 from David Cook <dcook@prosentient.com.au> --- It looks like the test plan uses the "/public/items" and "/public/biblios" endpoints but not the "/public/holds". I've placed a hold and then gone to try to change the pickup location for my hold but I can't... where does that endpoint get used? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #31 from David Cook <dcook@prosentient.com.au> --- Actually I can't find anywhere that uses the hold endpoint. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #192461|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #193373|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #32 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 195849 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195849&action=edit 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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #33 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- Created attachment 195850 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195850&action=edit Bug 41768: create and use public pickup_locations endpoints Sponsored-by: BibLibre -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #34 from David Cook <dcook@prosentient.com.au> --- Please stop marking your own patches as "Signed Off". -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #35 from Arthur Suzuki <arthur.suzuki@biblibre.com> --- (In reply to David Cook from comment #34)
Please stop marking your own patches as "Signed Off".
I'm sorry that was not intentional, I see you fixed the status, thanks for that -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 --- Comment #36 from David Cook <dcook@prosentient.com.au> --- (In reply to Arthur Suzuki from comment #35)
(In reply to David Cook from comment #34)
Please stop marking your own patches as "Signed Off".
I'm sorry that was not intentional, I see you fixed the status, thanks for that
I've noticed it's happened a few times now. It could be worth reviewing your dev environment to make sure you're not somehow automatically changing it. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41768 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41313 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org