For, at least, the ERM module we would like to retrieve the authorised values for a given category to build a dropdown list with the different options. It has been decided on bug 17390 to use GET /authorised_value_categories/:authorised_value_category_id/values
Created attachment 146730 [details] [review] Bug 32981: Add endpoint to get AV for given category For, at least, the ERM module we would like to retrieve the authorised values for a given category to build a dropdown list with the different options. It has been decided on bug 17390 to use GET /authorised_value_categories/:authorised_value_category_id/values Test plan: curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/LOC/values Should display the list of LOC curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/xLOCx/values Should return a 404
Working as intended, also good to see bug 17390 being broken down so that we can at least get the AV values, we can think about create, update and delete later, as stated by Josef in that bug. Do we really need a custom to_api_mapping, or should we instead change some of the fields in authorised_values e.g. lib and lib_opac.
Created attachment 146842 [details] [review] Bug 32981: Add endpoint to get AV for given category For, at least, the ERM module we would like to retrieve the authorised values for a given category to build a dropdown list with the different options. It has been decided on bug 17390 to use GET /authorised_value_categories/:authorised_value_category_id/values Test plan: curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/LOC/values Should display the list of LOC curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/xLOCx/values Should return a 404 Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
(In reply to Pedro Amorim from comment #2) > Do we really need a custom to_api_mapping, or should we instead change some > of the fields in authorised_values e.g. lib and lib_opac. Yes, we list the names of the attributes we want to modify there.
I know! :-D My point is we wouldn't want to modify the names of the attributes if they were already straightforward enough.
Created attachment 147335 [details] [review] Bug 32981: Add endpoint to get AV for given category For, at least, the ERM module we would like to retrieve the authorised values for a given category to build a dropdown list with the different options. It has been decided on bug 17390 to use GET /authorised_value_categories/:authorised_value_category_id/values Test plan: curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/LOC/values Should display the list of LOC curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/xLOCx/values Should return a 404 Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 147336 [details] [review] Bug 32981: (QA follow-up) Fix POD and file permissions
Question: are we sure about the names for things? I would've expected to see something like: my $avs_rs = $category->avs; for querying the avs. Let's suppose we leave that for later, for when we really embed the avs in the /authorised_value_categories endpoint... Are you sure we will call the accessor $category->values instead? And so the x-koha-embed attribute. I'm not saying it is wrong, just thinking it might get confusing. I'd go for 'av', like in /av_categories /av_categories/:code/avs I'm not even sure we need this endpoint or just the other one, with an embed :-D GET /av_categories/:code x-koha-embed: avs
(In reply to Tomás Cohen Arazi from comment #8) > I'm not even sure we need this endpoint or just the other one, with an embed It's not used later, feel free to drop it. It felt "more REST" than the other route, that's why I decided to keep it.
I'm still in doubt with comment 8. Please tell me what are your thoughts. It feels like the name for things needs some thought.
Pushed to master for 23.05. Nice work everyone, thanks!
Nice work everyone! Pushed to stable for 22.11.x
This seems to break the complete API. See also bug 32983.
Enhancement will not be backported to 22.05.x.
*** Bug 17390 has been marked as a duplicate of this bug. ***