|
Description
Nick Clemens (kidclamp)
2022-10-14 14:34:26 UTC
Created attachment 142628 [details] [review] Bug 31974: Regression: Bug 31813 incorrectly affected labels in the header search This patch adds a specific white-space property to header search labels so that they do not wrap. The change made by Bug 31813 overrode the white-space property incorrectly. To test, apply the patch and rebuild the staff interface CSS. - Go to Administration. - The header search label "Search system preferences" should appear on one line. - Check that labels still wrap correctly on pages like the patron edit screen and the staged MARC record detail view. Created attachment 144458 [details] [review] Bug 31794: Add REST endpoint to get an authority To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Get the id of an authority 4. Make a GET request to /api/v1/authorities/{authid} with one of the following content type header - application/json - application/marcxml+xml - application/marc-in-json - application/marc - text/plain 5. Check that you get the authority in the corresponding format 6. Sign off Created attachment 144460 [details] [review] Bug 31794: Add REST endpoint to get an authority To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Get the id of an authority 4. Make a GET request to /api/v1/authorities/{authid} with one of the following content type header - application/json - application/marcxml+xml - application/marc-in-json - application/marc - text/plain 5. Check that you get the authority in the corresponding format 6. Sign off Signed-off-by: David Nind <david@davidnind.com> Testing notes (using KTD): 1. I used the curl command to test the different content header types: curl -u koha:koha -i -H 'Accept:text/plain' http://127.0.0.1:8080/api/v1/authorities/419 Created attachment 144484 [details] [review] Bug 31794: Add REST endpoint to get an authority To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Get the id of an authority 4. Make a GET request to /api/v1/authorities/{authid} with one of the following content type header - application/json - application/marcxml+xml - application/marc-in-json - application/marc - text/plain 5. Check that you get the authority in the corresponding format 6. Sign off Signed-off-by: David Nind <david@davidnind.com> Created attachment 144485 [details] [review] Bug 31794: (follow-up) Add description to authorities tag (In reply to David Nind from comment #4) > Testing notes (using KTD): > > 1. I used the curl command to test the different content header types: > curl -u koha:koha -i -H 'Accept:text/plain' > http://127.0.0.1:8080/api/v1/authorities/419 Hi David, thanks for testing.. sorry for the confusion, it was not the "Content-Type" header, it was "Accept" as you correctly used it Created attachment 146338 [details] [review] Bug 31794: Add REST endpoint to get an authority To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Get the id of an authority 4. Make a GET request to /api/v1/authorities/{authid} with one of the following content type header - application/json - application/marcxml+xml - application/marc-in-json - application/marc - text/plain 5. Check that you get the authority in the corresponding format 6. Sign off Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Created attachment 146339 [details] [review] Bug 31794: (follow-up) Add description to authorities tag Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Works as described, tests pass, wondering if we should DRY this in Authority.pm, or not worth:
152 C4::Context->preference('marcflavour') eq 'UNIMARC'
153 ? 'UNIMARCAUTH'
154 : 'MARC21';
Looks good to me. But I think we should add the public path there too just as we do for displaying a biblio record. Please add it. Thanks. (In reply to Marcel de Rooy from comment #11) > Looks good to me. But I think we should add the public path there too just > as we do for displaying a biblio record. Please add it. Thanks. I'm sorry, but wanting another more feature should not be failing this endpoint dev. (In reply to Tomás Cohen Arazi from comment #12) > I'm sorry, but wanting another more feature should not be failing this > endpoint dev. Please note that the reason is not asking more functionality but lack of consistency. I agree that it is arguable if we should fail here, but we have been adding incomplete developments so often.. Opening a new report and expressing commitment to finalize might be helpful to convince me. See IRC. Resuming here now Come back here monday. Issues with the api test, but maybe related to a local dev change (In reply to Marcel de Rooy from comment #15) > Come back here monday. Issues with the api test, but maybe related to a > local dev change There is trouble in the current API with authorised values somehow. See 32981 and 32983 that currently prevent me from testing this properly. Created attachment 147778 [details] [review] Bug 31794: Add REST endpoint to get an authority To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Get the id of an authority 4. Make a GET request to /api/v1/authorities/{authid} with one of the following content type header - application/json - application/marcxml+xml - application/marc-in-json - application/marc - text/plain 5. Check that you get the authority in the corresponding format 6. Sign off Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 147779 [details] [review] Bug 31794: (follow-up) Add description to authorities tag Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Well, i tested this now on top of commit commit fe872b792037ee2f8cce0d25f95c1e4f739ffe49 Author: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> Date: Thu Feb 2 12:45:04 2023 -0500 Bug 32803: EnableItemGroups and EnableItemGroupHolds options are wrong And that it works fine. After 32981 things break. Pushed to master for 23.05. Nice work everyone, thanks! Enhancement - not backporting to 22.11.x. Setting to Needs documenting. Nice work everyone! The API's are self documenting (i.e. the swagger spec is the documentation and gets pushed to api.koha-community.org on pushes) |