|
Description
Pedro Amorim
2023-02-17 15:12:31 UTC
Hi, what we need is:
GET /av_categories?q={"av_category_id":["av_1",...,"av_n"]}
x-koha-embed: authorised_values:string
The caveat about :string is that Jonathan is proposing on bug 32981 to return the full AV objects on the avs endpoint. But if the embed didn't include :string and only did the usual thing for embedding related objects, it would be good enough.
Note: the idea behind :string is that it would 'calculate the right strings according to the context' (e.g. public? just the description for a dropdown?) but I don't have a clear idea for this particular use case so I'd move forward with what I proposed, without :string.
Created attachment 146970 [details] [review] Bug 32997: Add REST API endpoint to list authorised values for multiple given categories This patch adds /api/v1/authorised_value_categories endpoint that retrieves authorised value categories for the given names and their authorised values if x-koha-embed: authorised_values is also given. To test: Apply patch curl -u koha:koha --request GET \"http://localhost:8081/api/v1/authorised_value_categories?q=%5B%5B%7B%22me.category_name%22%3A%5B%22LOC%22%2C%22YES_NO%22%5D%7D%5D%5D\" --header \"x-koha-embed:authorised_values\" 11 parameters: 12 - name: category_names 13 in: query 14 description: Case insensitive search on category name 15 required: false 16 type: array 17 - name: x-koha-embed You have an extra 's' here, it should be category_name, or maybe even just 'name' (and add the mapping to Koha::AuthorisedValueCategory->to_api_mapping). Created attachment 147224 [details] [review] Bug 32997: Add REST API endpoint to list authorised values for multiple given categories This patch adds /api/v1/authorised_value_categories endpoint that retrieves authorised value categories for the given names and their authorised values if x-koha-embed: authorised_values is also given. To test: Apply patch curl -u koha:koha --request GET \"http://localhost:8081/api/v1/authorised_value_categories?q=%7B%22me.category_name%22%3A%5B%22LOC%22%2C%22YES_NO%22%5D%7D\" --header \"x-koha-embed:authorised_values\" (In reply to Jonathan Druart from comment #3) > 11 parameters: > 12 - name: category_names > 13 in: query > 14 description: Case insensitive search on category name > 15 required: false > 16 type: array > 17 - name: x-koha-embed > > You have an extra 's' here, it should be category_name, or maybe even just > 'name' (and add the mapping to > Koha::AuthorisedValueCategory->to_api_mapping). Actually, I don't think that parameter is needed at all, since the category names are going into the query (q) param, correct? Tested it and provided a new patch with it removed. Created attachment 147237 [details] [review] Bug 32997: Add REST API endpoint to list authorised values for multiple given categories Add tests Created attachment 147296 [details] [review] Bug 32997: Add tests Commit message fix Created attachment 147340 [details] [review] Bug 32997: Add REST API endpoint to list authorised values for multiple given categories This patch adds /api/v1/authorised_value_categories endpoint that retrieves authorised value categories for the given names and their authorised values if x-koha-embed: authorised_values is also given. To test: Apply patch curl -u koha:koha --request GET \"http://localhost:8081/api/v1/authorised_value_categories?q=%7B%22me.category_name%22%3A%5B%22LOC%22%2C%22YES_NO%22%5D%7D\" --header \"x-koha-embed:authorised_values\" Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Created attachment 147341 [details] [review] Bug 32997: Add tests Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Created attachment 147640 [details] [review] Bug 32997: (QA follow-up) values => authorised_values This patch renames that for consistency, and also makes use of the ->authorised_values accessor on the category. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Pushed to master for 23.05. Nice work everyone, thanks! Nice work everyone! Pushed to stable for 22.11.x Enhancement will not be backported to 22.05.x Back end stuff, doesn't affect the end user so there's nothing to add/amend in the manual. I'm told the API docs is automated, so there's no need to put those bugs as Needs documenting. |