Summary: | Add PUT endpoint for Biblios | ||
---|---|---|---|
Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
Component: | REST API | Assignee: | Agustín Moyano <agustinmoyano> |
Status: | CLOSED FIXED | QA Contact: | Kyle M Hall (khall) <kyle> |
Severity: | new feature | ||
Priority: | P5 - low | CC: | bibliothek, caroline.cyr-la-rose, dcook, hammat.wele, julian.maurice, kyle, lucas, martin.renvoize, maryse.simard, olivier.hubert, philippe.blouin, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30799 | ||
Change sponsored?: | Sponsored | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
23.05.00,22.11.04
|
|
Circulation function: | |||
Bug Depends on: | 31800 | ||
Bug Blocks: | 35380, 31788, 32734 | ||
Attachments: |
Bug 31801: Add REST endpoint to modify a biblio
Bug 31801: Add REST endpoint to modify a biblio Bug 31801: Add REST endpoint to modify a biblio Bug 31801: Add REST endpoint to modify a biblio Bug 31801: Add REST endpoint to modify a biblio |
Description
Nick Clemens (kidclamp)
2022-10-14 14:41:59 UTC
Created attachment 144832 [details] [review] Bug 31801: Add REST endpoint to modify a biblio To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Pick a biblio to modify, and modify it's marc record 4. Make a PUT request to /api/v1/biblios/:biblionumber with one of the following content type header - application/json - application/marcxml+xml - application/marc-in-json - application/marc 5. If content type is other than 'application/json' place the following header in the request 'x-framework-id: <framework id>' 5. Check that the biblio was modified 6. Sign off Created attachment 144836 [details] [review] Bug 31801: Add REST endpoint to modify a biblio To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Pick a biblio to modify, and modify it's marc record 4. Make a PUT request to /api/v1/biblios/:biblionumber with one of the following content type header - application/marcxml+xml - application/marc-in-json - application/marc 5. Add the following header in the request 'x-framework-id: <framework id>' 5. Check that the biblio was modified 6. Sign off Created attachment 144838 [details] [review] Bug 31801: Add REST endpoint to modify a biblio To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Pick a biblio to modify, and modify it's marc record 4. Make a PUT request to /api/v1/biblios/:biblionumber with one of the following content type header - application/marcxml+xml - application/marc-in-json - application/marc 5. Add the following header in the request 'x-framework-id: <framework id>' 5. Check that the biblio was modified 6. Sign off Great that this route is going to be implemented in core. There is plugin available at https://github.com/NatLibFi/koha-plugin-rest-biblios. I found that if MARCOverlayRules are used, f.e. protect field 100 from being overwritten, the field is overwritten if api is used. Can you verify this? A modified test plan would be 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Add Marc overlay rule in administration / MARC overlay rules module = source filter = * tag = 001 preset = protect 4. Set MARCOverlayRules to Use in system prefs 5. Pick a biblio to modify, and modify it's marc record especially field 001 6. Make a PUT request to /api/v1/biblios/:biblionumber with one of the following content type header - application/marcxml+xml - application/marc-in-json - application/marc 7. Add the following header in the request 'x-framework-id: <framework id>' 8. Check that the biblio was modified but not field 001 To respect MARCOverlayRules the call of ModBiblio could be extended like this: ModBiblio( $record, $biblionumber, $frameworkcode, { overlay_context => { source => 'API biblios' } } ); Shall i write another patch or can you change the line? Created attachment 147146 [details] [review] Bug 31801: Add REST endpoint to modify a biblio To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Pick a biblio to modify, and modify it's marc record 4. Make a PUT request to /api/v1/biblios/:biblionumber with one of the following content type header - application/marcxml+xml - application/marc-in-json - application/marc 5. Add the following header in the request 'x-framework-id: <framework id>' 5. Check that the biblio was modified 6. Sign off Signed-off-by: Hammat Wele <hammat.wele@inlibro.com> Created attachment 147718 [details] [review] Bug 31801: Add REST endpoint to modify a biblio To test: 1. Apply patch 2. Set RESTBasicAuth preference to true 3. Pick a biblio to modify, and modify it's marc record 4. Make a PUT request to /api/v1/biblios/:biblionumber with one of the following content type header - application/marcxml+xml - application/marc-in-json - application/marc 5. Add the following header in the request 'x-framework-id: <framework id>' 5. Check that the biblio was modified 6. Sign off Signed-off-by: Hammat Wele <hammat.wele@inlibro.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> I am sorry to ask again (see comment #4 & #5). Shouldn't this route respect MARCOverlayRules, if set in Administration? (In reply to Jan Kissig from comment #5) > To respect MARCOverlayRules the call of ModBiblio could be extended like > this: > > ModBiblio( $record, $biblionumber, $frameworkcode, { overlay_context => { > source => 'API biblios' } } ); > > Shall i write another patch or can you change the line? Since Jan already provided the solution - how can we best move forward here? I agree that the rules should be respected. Maybe we could move the change to a separate bug and also extend the 'filters' pull-down list on the overly rules administration page with an API entry. Not sure if a new source needs to be defined in other spots as well. (In reply to Katrin Fischer from comment #9) > (In reply to Jan Kissig from comment #5) > > To respect MARCOverlayRules the call of ModBiblio could be extended like > > this: > > > > ModBiblio( $record, $biblionumber, $frameworkcode, { overlay_context => { > > source => 'API biblios' } } ); > > > > Shall i write another patch or can you change the line? > > Since Jan already provided the solution - how can we best move forward here? > I agree that the rules should be respected. > > Maybe we could move the change to a separate bug and also extend the > 'filters' pull-down list on the overly rules administration page with an API > entry. Not sure if a new source needs to be defined in other spots as well. I agree, but this is gonna be more complex :-D We are adding a new table for record sources on bug 32607 (In reply to Jan Kissig from comment #5) > To respect MARCOverlayRules the call of ModBiblio could be extended like > this: > > ModBiblio( $record, $biblionumber, $frameworkcode, { overlay_context => { > source => 'API biblios' } } ); This is an interesting point. If we think we will eventually replace our current code with an API-driven UI, having an 'API biblios' record source doesn't feel useful. That's why we are introducing the concept of configurable record sources on bug 32607. With that in mind, the record source will be undefined in case of regular cataloguing, or a specific one based on a header with an allow list of users that can impersonate the record source. Once we have that, we can move the cataloguing sources in the MARC overlay rules pages into the record sources tables, and adapt the code so it is used from there. (In reply to Tomás Cohen Arazi from comment #11) > (In reply to Jan Kissig from comment #5) > > To respect MARCOverlayRules the call of ModBiblio could be extended like > > this: > > > > ModBiblio( $record, $biblionumber, $frameworkcode, { overlay_context => { > > source => 'API biblios' } } ); > > This is an interesting point. If we think we will eventually replace our > current code with an API-driven UI, having an 'API biblios' record source > doesn't feel useful. > > That's why we are introducing the concept of configurable record sources on > bug 32607. With that in mind, the record source will be undefined in case of > regular cataloguing, or a specific one based on a header with an allow list > of users that can impersonate the record source. > > Once we have that, we can move the cataloguing sources in the MARC overlay > rules pages into the record sources tables, and adapt the code so it is used > from there. source => 'API biblios' in my comment #5 was just something like a placeholder for me and I didn't find anything that suited for the API routes. But without overlay_context any MARC overlay rules will be checked. Pushed to master for 22.11. Nice work everyone, thanks! Nice work, thanks everyone! Pushed to 22.11.x for the next release. *** Bug 30799 has been marked as a duplicate of this bug. *** Enhancement will no be backported to 22.05.x |