Summary: | Add unprivileged route to get a bibliographic record | ||
---|---|---|---|
Product: | Koha | Reporter: | Tomás Cohen Arazi (tcohen) <tomascohen> |
Component: | REST API | Assignee: | Tomás Cohen Arazi (tcohen) <tomascohen> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | 1joynelson, aleisha, david, dcook, jonathan.druart, lucas, martin.renvoize, tomascohen, victor |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
20.05.00, 19.11.07
|
|
Circulation function: | |||
Bug Depends on: | 23677 | ||
Bug Blocks: | 29890, 17371, 25045 | ||
Attachments: |
Bug 24909: Unit tests
Bug 24909: Route spec Bug 24909: Add unprivileged route to get a bibliographic record Bug 24909: Unit tests Bug 24909: Route spec Bug 24909: Add unprivileged route to get a bibliographic record Bug 24909: Unit tests Bug 24909: Route spec Bug 24909: Add unprivileged route to get a bibliographic record |
Description
Tomás Cohen Arazi (tcohen)
2020-03-19 15:29:51 UTC
It would be a handy addition so we can use JQuery to display more info on the biblios, and/or remove some old CGI scripts as well. We have svc/records/preview already This one is about the OPAC. I think you mean the other bug (24908). But you are right about that. I want to introduce new things to the API and deprecate the old scripts. Created attachment 101057 [details] [review] Bug 24909: Unit tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Created attachment 101058 [details] [review] Bug 24909: Route spec Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Created attachment 101059 [details] [review] Bug 24909: Add unprivileged route to get a bibliographic record This patch adds a route to get bibliographic records without privileged access. This needs to match the OPAC expected behaviour. Some things were considered on the implementation: - The ViewPolicy filter that hides/shows things based on the frameworks needded to be used, as in the OPAC. - OpacHiddenItems and OpacHiddenItemsExceptions need to be considered for hiding records the same way the OPAC is expected to. - Avoid using OpacHiddenItemsExceptions, but rely on the patron category instead (use Koha::Patron::Category->override_hidden_items abstraction is used instead so it should keep working once 22547 is moved forward). - Tests should cover all the use cases: * logged in user * anonymous user * logged in with category that overrides * logged in with category that doesn't override This is all implemented on the tests. To test: 1. Apply the tests patch 2. Run: $ kshell k$ prove t/db_dependent/api/v1/biblios.t => FAIL: Route not implemented 3. Apply the rest of the patches 4. Repeat 2 => SUCCESS: Tests pass! 5. Try it with your favourite API tool (Postman?) 6. Sign off :-D Note: please notice there isn't a default fallback behaviour for when you don't specify the Accept header, so testing this on a regular browser will just print the accepted mime types instead of the record itself. To test this with a tool (like Postman) you should enable RESTBasicAuthe and make the tool use Basic authentication with valid credentials. And you need to specify any of the following strings on the Accept header: - application/marcxml+xml - application/marc-in-json - application/marc - text/plain Created attachment 102163 [details] [review] Bug 24909: Unit tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Created attachment 102164 [details] [review] Bug 24909: Route spec Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Created attachment 102165 [details] [review] Bug 24909: Add unprivileged route to get a bibliographic record This patch adds a route to get bibliographic records without privileged access. This needs to match the OPAC expected behaviour. Some things were considered on the implementation: - The ViewPolicy filter that hides/shows things based on the frameworks needded to be used, as in the OPAC. - OpacHiddenItems and OpacHiddenItemsExceptions need to be considered for hiding records the same way the OPAC is expected to. - Avoid using OpacHiddenItemsExceptions, but rely on the patron category instead (use Koha::Patron::Category->override_hidden_items abstraction is used instead so it should keep working once 22547 is moved forward). - Tests should cover all the use cases: * logged in user * anonymous user * logged in with category that overrides * logged in with category that doesn't override This is all implemented on the tests. To test: 1. Apply the tests patch 2. Run: $ kshell k$ prove t/db_dependent/api/v1/biblios.t => FAIL: Route not implemented 3. Apply the rest of the patches 4. Repeat 2 => SUCCESS: Tests pass! 5. Try it with your favourite API tool (Postman?) 6. Sign off :-D Note: please notice there isn't a default fallback behaviour for when you don't specify the Accept header, so testing this on a regular browser will just print the accepted mime types instead of the record itself. To test this with a tool (like Postman) you should enable RESTBasicAuthe and make the tool use Basic authentication with valid credentials. And you need to specify any of the following strings on the Accept header: - application/marcxml+xml - application/marc-in-json - application/marc - text/plain Signed-off-by: David Nind <david@davidnind.com> Note: text/plain is not an available option for Accept header. (In reply to David Nind from comment #10) > Note: text/plain is not an available option for Accept header. Right, I can write a follow-up for that. I wrote that for the privileged access API before writing this one! What happens if OpacPublic is disabled? For me: tests still pass, as basic authentication is enabled the requests with Accept headers still work as well. (In reply to Jonathan Druart from comment #12) > What happens if OpacPublic is disabled? Nothing. All routes that are in the /public namespace can be disabled using the RESTPublicAPI syspref. We are not going to add tests for that in this bug, as it is tested generally in t/db_dependent/api/auth.t:50 onwards (bug 22061). (In reply to Tomás Cohen Arazi from comment #11) > (In reply to David Nind from comment #10) > > Note: text/plain is not an available option for Accept header. > > Right, I can write a follow-up for that. I wrote that for the privileged > access API before writing this one! Waiting for the follow-up. (In reply to Jonathan Druart from comment #15) > (In reply to Tomás Cohen Arazi from comment #11) > > (In reply to David Nind from comment #10) > > > Note: text/plain is not an available option for Accept header. > > > > Right, I can write a follow-up for that. I wrote that for the privileged > > access API before writing this one! > > Waiting for the follow-up. This route correctly implements Accept: text/plain, already. So back to SO. Created attachment 103672 [details] [review] Bug 24909: Unit tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Created attachment 103673 [details] [review] Bug 24909: Route spec Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Created attachment 103674 [details] [review] Bug 24909: Add unprivileged route to get a bibliographic record This patch adds a route to get bibliographic records without privileged access. This needs to match the OPAC expected behaviour. Some things were considered on the implementation: - The ViewPolicy filter that hides/shows things based on the frameworks needded to be used, as in the OPAC. - OpacHiddenItems and OpacHiddenItemsExceptions need to be considered for hiding records the same way the OPAC is expected to. - Avoid using OpacHiddenItemsExceptions, but rely on the patron category instead (use Koha::Patron::Category->override_hidden_items abstraction is used instead so it should keep working once 22547 is moved forward). - Tests should cover all the use cases: * logged in user * anonymous user * logged in with category that overrides * logged in with category that doesn't override This is all implemented on the tests. To test: 1. Apply the tests patch 2. Run: $ kshell k$ prove t/db_dependent/api/v1/biblios.t => FAIL: Route not implemented 3. Apply the rest of the patches 4. Repeat 2 => SUCCESS: Tests pass! 5. Try it with your favourite API tool (Postman?) 6. Sign off :-D Note: please notice there isn't a default fallback behaviour for when you don't specify the Accept header, so testing this on a regular browser will just print the accepted mime types instead of the record itself. To test this with a tool (like Postman) you should enable RESTBasicAuthe and make the tool use Basic authentication with valid credentials. And you need to specify any of the following strings on the Accept header: - application/marcxml+xml - application/marc-in-json - application/marc - text/plain Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Nice work everyone! Pushed to master for 20.05 feature not backported to 19.11.x Is there any possibility that this could be backported to 19.11? Would be very helpful to have biblios endpoint accessible in the OPAC. backported to 19.11.x for 19.11.07 @aleisha: you should consider backporting bug 25045 and bug 25327 as well. It is your call, but we found out bug 25045 would be required during the QA round to allow disabling anonymous access. Enhancement not backported to oldoldstable (19.05.x) Also missing dependency: bug 23677 (In reply to Tomás Cohen Arazi from comment #24) > @aleisha: you should consider backporting bug 25045 and bug 25327 as well. > It is your call, but we found out bug 25045 would be required during the QA > round to allow disabling anonymous access. not backporting 25045 to 19.11.x due to the db update Unless I'm missing something, this doesn't take into account OpacSuppression. Is that right? |