It would be helpful to have a pre-filtered public endpoint for fetching and listing items.
Created attachment 147781 [details] [review] Bug 33146: Add public items lookup route This patch adds a /public equivilent to the item listing endpoint. This allows us to search for an item by it's external_id (barcode). Test plan 1. Apply patch 2. Perform a GET on /api/v1/public/items?external_id=some_barcode 3. Confirm that the above endpoint correctly returns items that should be visible in the OPAC
Created attachment 147786 [details] [review] Bug 33146: Unit tests
Created attachment 147787 [details] [review] Bug 33146: Add public items lookup route This patch adds a /public equivilent to the item listing endpoint. This allows us to search for an item by it's external_id (barcode). Test plan 1. Apply patch 2. Perform a GET on /api/v1/public/items?external_id=some_barcode 3. Confirm that the above endpoint correctly returns items that should be visible in the OPAC
Created attachment 147863 [details] [review] Bug 33146: Unit tests Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 147864 [details] [review] Bug 33146: Add public items lookup route This patch adds a /public equivilent to the item listing endpoint. This allows us to search for an item by it's external_id (barcode). Test plan 1. Apply patch 2. Perform a GET on /api/v1/public/items?external_id=some_barcode 3. Confirm that the above endpoint correctly returns items that should be visible in the OPAC Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
I seem to remember a lot of discussion on another bug about a public endpoint for items. There are a lot of fields with information libraries might not want to make publicly available. I see items itself are filtered by visibility, but what about columns? Internal note, vendor and price information, materials (pref driven)?
And for locations and similar - is only the OPAC description made visible publicly?
There's a trick going on with the allow list of attributes for the public API. For authorized value expansion, see bug 33161 for how we will implement that bit
As Tomas states, we are working on the `+strings` embed part of this distinctly, and I don't attempt to handle the additional subfields Marc stuff deliberately for this reason. We also already agreed on the public fields include back in bug 27358 where we introduced the first 'public_read_list' implementation. Hope that settles your nerves a bit Katrin.. this is of course rather important to get right. This is also a somewhat simpler case as it's a direct endpoint rather than an embed which has its own additional complications.
All ok, better to ask than to be sorry. :) I am glad you got it all handled and didn't remember we had finished bug 27358.
The tests here die if you have any issues in your system. Can we remove the delete, and add a common attribute to the newly created items that we can use to query and limit the data set?
(In reply to Nick Clemens from comment #11) > The tests here die if you have any issues in your system. Can we remove the > delete, and add a common attribute to the newly created items that we can > use to query and limit the data set? What I always do is generating a few items, and generate a my $query = { itemnumber => [ $item_1->id, ..., $item_n->id ] }; and then: $t->get_ok( '...?q=' . $query );
Created attachment 149014 [details] [review] Bug 33146: Unit tests Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 149015 [details] [review] Bug 33146: Add public items lookup route This patch adds a /public equivilent to the item listing endpoint. This allows us to search for an item by it's external_id (barcode). Test plan 1. Apply patch 2. Perform a GET on /api/v1/public/items?external_id=some_barcode 3. Confirm that the above endpoint correctly returns items that should be visible in the OPAC Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 149016 [details] [review] Bug 33146: (QA follow-up) Do not delete all items in test Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 149017 [details] [review] Bug 33146: Allow embedding expanded coded values Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 149019 [details] [review] Bug 33146: (QA follow-up) Consistency with /biblios/:biblio_id/items Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 149024 [details] [review] Bug 33146: Unit tests Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 149025 [details] [review] Bug 33146: Add public items lookup route This patch adds a /public equivilent to the item listing endpoint. This allows us to search for an item by it's external_id (barcode). Test plan 1. Apply patch 2. Perform a GET on /api/v1/public/items?external_id=some_barcode 3. Confirm that the above endpoint correctly returns items that should be visible in the OPAC Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Bug 33146: (QA follow-up) Do not delete all items in test Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Bug 33146: Allow embedding expanded coded values Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Bug 33146: (QA follow-up) Consistency with /biblios/:biblio_id/items Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Bug 33146: (QA follow-up) Make sure public API enabled for tests Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Pushed to master for 23.05. Nice work everyone, thanks!
Enhancement - not backporting to 22.11.x Nice work everyone!