Test plan:
Request the /items REST API endpoint and ask for the biblio's info to be
embeded into the response passing x-koha-embed
curl -u koha:koha --request GET 'http://localhost:8081/api/v1/items' --header "x-koha-embed: biblio" --header "Content-Type: application/json"
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Andreas Roussos <a.roussos@dataly.gr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the `cancellation_requested` attribute to the hold
object definition, and allows embeding it as on the different holds
endpoints that migt be useful.
To test:
1. Apply this patches
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Hold.t \
t/db_dependent/api/v1/*holds.t
=> SUCCESS: Tests pass!
3. Play with your REST tool (Postman?) on the following endpoints:
GET http://localhost:8081/api/v1/holds
GET http://localhost:8081/api/v1/patrons/:patron_id/holds
on both, pass and not pass the `x-koha-embed` header with
`cancellation_requested` on it.
=> SUCCESS: It is easy! You see the attribute and you don't, and the
content makes sense!
4. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The API route for listing all suggestion:
/api/v1/suggestions
send back an error message when there is a suugestion with non standard
status (ASKED, CHECKED, ACCEPTED, REJECTED).
This patch fixes this too restrictive restriction.
TO TEST:
1. Add a status in SUGGEST_STATUS AV list.
2. Create a suggestion, and assign it to the previsous status.
3. Call /api/v1/suggestion
3. You get an error message:
{
"errors": [ {
"message":"Not in enum list: ASKED, CHECKED, ACCEPTED, REJECTED.",
"path":"\/1\/status"
}],
"status":200
}
4. Apply the patch. Call /api/v1/suggestion
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currently the erm_eholdings_titles table has a field called preceeding_publication_title_id. This should be preceding_publication_title_id
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the password validation response return the following
patron attributes to the API consumer:
* cardnumber
* userid
This will give hints on what was used to validate in the fallback
bahvior the endpoint has.
To test:
1. Apply the unit tests patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/password_validation.t
=> FAIL: The endpoint doesn't return this valuable data
3. Apply this patch
4. Repeat 2
=> SUCESS: Tests pass! We got the cardnumber and the userid!
5. Sign off :-D
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Fixes the heading and sidebar display of the 'Import batches'
section.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: I removed the wrongly introduced import_batches.yaml file
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch aims to make our API docs be more consistent.
It addresses two particular things:
* There's no consistency on the `tags` used across the spec, and not all
of them are correctly described and have an `x-displayName` entry.
More on this later.
* This are not sorted either by some for of grouping, or at least
alphabetically.
For the former, I did my best trying to harmonize (specially on the ERM
front) with what we do in the rest of the use cases.
For the latter, I opted for sorting everything alphabetically, as a
first step. Hoping someone else could work on grouping things.
To test (ON YOUR HOST MACHINE):
1. On current master run:
$ cd api/v1/swagger
$ docker run --rm -v $(pwd):/api --workdir /api redocly/cli \
build-docs swagger.yaml --output index.html
=> SUCCESS: It doesn't break or anything
2. Open your browser, open the generated api/v1/swagger/index.html file
=> FAIL: The left column has
* several lower case entries
* not everything is correctly grouped (ERM? packages?)
* Things are not sorted. There's an attempt but looks messy
3. Apply this patch
4. Repeat 1 and 2
=> SUCCESS: Things look much better!
5. Sign off :-D
CAVEAT1: I'm not sure why, but import_batches doesn't work. Ideas are
welcome, I'll keep looking for fixes.
CAVEAT2: I don't have enough eHoldings background to weight in, but I
feel like 'ERM eHoldings packages' could just be 'ERM packages'.
Follw-up patches with better ideas are welcome.
CAVEAT3: Patron credits, debits, balance... They could all go in to
'Patrons accounts' or similar. Open to ideas.
CAVEAT4: Old redocly didn't support mapping an endpoint to more than one
target section. Something to explore if we want (for example) to reach
'credits' through the 'Patrons' section but also from 'Accounting'.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch takes a step forward on the password validation endpoint, by
adding the `identifier` parameter and making it be allowed
to be the patron's `cardnumber` or the `userid`.
The current `userid` only validation option is kept as-is.
The implementation relies on `C4::Auth::checkpw` to query for the
patron.
To test:
1. Apply this patches
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/password_validation.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds biblio details to the self-checkout modal. As part of
this we add 'biblio' to the x-koha-embed option on the public items
endpoint, clone the js-biblio-format include from the staff client
adapting it slightly for OPAC use along the way and also import
escape_str and escapeHtml from staff to opac too.
Signed-off-by: Silvia Meakins <smeakins@eso.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
vendor ID must be integer and date attributes should specify the format
accordingly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Includes removing q_header.
Inconsistent use of quotes for response codes.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Field <jonathan.fieeld@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The public api endpoint for self-checkout should only be enabled in the
case where the OpacTrustedSelfCheckout option is enabled.
Signed-off-by: Silvia Meakins <smeakins@eso.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch expands the checkouts endpoints to allow for a public workflow.
We add the availability endpoint under `/public/checkouts/availability`
and restrict the information we send back to only those fields a public
user should be allowed to see.
We also add a new checkout endpoint at `/patrons/{patron_id}/checkouts`
that allows for users to checkout to themselves and accepts the same POST
request with checkout details including item_id and a confirmation token
in the body that the staff client endpoints accept.
Signed-off-by: Silvia Meakins <smeakins@eso.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Allow to embed stringified version of attributes for the "Get items for
a biblio" endpoint
Test plan:
curl -u koha:koha --request GET 'http://localhost:8081/api/v1/biblios/47/items' --header "Content-Type: application/json" --header "x-koha-embed: +strings" | jq
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If checked_in flag is passed we return the "old checkouts". But if the
item has been deleted we explode with
"message":"Expected integer - got null.","path":"\/0\/item_id"
The specs should reflect that an item can have been deleted.
Test plan:
Hit the endpoint and confirm the above.
Can be done easily using curl:
curl -u koha:koha --request GET 'http://localhost:8081/api/v1/checkouts?patron_id=5&checked_in=1' --header "Content-Type: application/json" | jq
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch should resolve the issues highlighted at signoff time by
Victor.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This could be extended later in bug 32968 to pass the permission of the
logged in user.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
At some point in the patch series we lost the availability api schema.
This patch restores a basic version, but we should work towards a
clearer enum based schema for each of the available blockers, confirms
and warnings.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch introduces a public endpoint for cancelling holds.
Cancellation requests are generated when the hold is waiting and
configuration allows requesting cancellation, as the OPAC does right
now.
Tests cover all the use cases.
To test:
1. Apply this patches
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/patrons_holds.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes support for the `x-koha-query` header entirely from
the codebase. For the purpose:
- $c->objects->search is adjusted
- Relevant tests are cleared/adapted
- The OpenAPI spec gets the header removed
To test:
1. Apply this patch and run:
$ ktd --shell
k$ prove t/db_dependent/Koha/REST/Plugin/Objects.t \
t/Koha/REST/Plugin/Query.t \
t/db_dependent/api/v1/*.t
=> SUCCESS: Tests pass!
2. Sign off :-D
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds API's to allow for a checkout flow using the RESTful
API.
We add an availability endpoint to check an items current availability
status. The endpoint can be found at `/checkouts/availability` and is
a GET request that requires item_id and patron_id passed as parameters.
We return an availability object that includes blockers, confirms,
warnings and a confirmation token to be used for checkout.
We also add a corresponding checkout method to the `/checkouts` endpoint.
The method accepts a POST request with checkout details including item_id
, patron_id and the confirmation token in the body.
Future work: We should properly migrate CanBookBeIssued into Koha::* and
use that here instead of refering to C4::Circulation.
Signed-off-by: Silvia Meakins <smeakins@eso.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows the requested_date for an ILL request to be NULL to accomodate
older data
To test:
1 - Install the Koha 2 Koha ILL plugin:
https://gitlab.com/koha-community/plugins/koha-plugin-ill-koha
2 - Enable the ILL system preference
3 - Force an ILL request with minimal data from backend:
INSERT INTO illrequests (borrowernumber,biblio_id,branchcode,backend,status) VALUES (5,3,'CPL','Koha','placed');
4 - View the ILL table
5 - Error:
{"message":"Expected string - got null.","path":"\/body\/0\/requested_date"}
6 - Apply patch
7 - Table loads successfully
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds order_receive to the list of permissions that allow the
endpoint to return orders.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Sharon Dugdale <Sharon.Dugdale@cumberland.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates instances in the code and templates where the term
"Authentication providers" is used, replacing it with the preferred
"Identity provider."
Most of the instances of this change are in module or API documentation,
but you can see a couple of the changes in the interface:
- Administration -> Identity providers:
- The sidebar menu should show "Identity providers" instead of
"Authentication providers."
- Patrons -> Patron details -> More -> Set permissions
- Under " Manage Koha system settings (Administration panel)" you
should see "Manage identity providers (manage_identity_providers)"
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This change fixes the definition for the non-public endpoint for the OAuth/OIDC
implementation.
It also uses the non-public endpoint for the staff interface UI.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch implements the code to allow a patron to receive multiple
orders at the same time in /cgi-bin/koha/acqui/orderreceive.pl page
To test:
1. apply all patches
2. updatedatabase
3. Go to system preferences and allow AcqReceiveMultipleOrderLines
4. In acquisitions module, create a vendor if you don't have one and add
3 baskets.. one with create items on ordering, one with create items
on receiving and finally one with create items when cataloguing
5. Fill baskets with orders (There should be at least 15 orders in total). There should be a mix of orders created by suggestions, others by subscriptions and others by neither of those methods.
6. Close all baskets and receive shipment.
CHECK => in /cgi-bin/koha/acqui/parcel.pl page, in top table there is a column with checkboxes, and a button that says "Receive selected"
7. If all orders from all baskets are shown in the table, set the rows per page to 10, so table has more than one page
8. Check some of the checkboxes
CHECK => "Receive selected" button shows how many rows are selected
9. Go to the next page and select some more rows
CHECK => Changing page does not modify how many rows where selected
10. Go back to previous page
CHECK => Previously selected rows are still selected
11. Reload the page to deselect all rows
12. Select only one row and click on "Receive selected" button
CHECK => the page /cgi-bin/koha/acqui/orderreceive.pl behaves just the same as if the "receive" link in the selected row would have been clicked.
13. Click on cancel to go back to parcel.pl page
14. Select all rows (even the ones from the next page of the table) and
click on "Receive selected"
CHECH => In orderreceive.pl page there is a table with all selected rows
15. Ensure table has more than one page, as in step 7
16. Click on the "edit" link in the last row of the current page
CHECK => A modal window is displayed with 4 tabs within: Info,
Accounting, Receipt history and Items
CHECK => Modal has 4 buttons at the bottom, 'Previous' to go to previos
order, 'Cancel' to close the modal without keeping modifications, 'Save'
to close modal keeping modifications and 'Next' to go to the next order
CHECK => Even that we are at the end of the current page, 'Next' button
is still available
17. Click on 'Next' button
CHECK => The table behind the modal now displays the next page, and the modal was not closed
18. Click on 'Previous'
CHECK => The table behind the modal went back to the first page, and the modal was not closed
19. Click on 'Previous' button till you reach the first row of the first
page
CHECK => Only when you reach the first row of the first page 'Previous'
button gets disabled
20. Click on 'Next' button till you reach the last row of the last page
CHECK => Only when you reach the last button of the last page 'Next'
button gets disabled
21. Check that behaviour for the different types of order are still the
same
a. For orders that where created through suggestion, check that the
suggestion info is present in Info tab. If when suggestion was accepted
you set a reason, a dropdown to change the reason shoul display also.
b. For orders that where created through subscriptions, check that
the Items tab is disabled, and the Receipt history is enabled. On
accounting tab you should be able to change quantity ordered. If there
were less items received than ordered, the next time you receive this
order the child order generated from this one shoul appear in receipt
history.
c. For orders that don't come from subscription and creates there items on ordering, Receipt history
should be disabled, and a table with prefilled items shold appear in the
Items tab. You can edit them and the changes should appear in the item's
row.
d. For orders that don't come from subscription and creates there
items on receiving, Receipt history should be disabled, and a form to
create the items should appear in Items tab. When you add an item a
table should appear.
e. For orders that don't come from subscription and creates there
ites on cataloguing, Receipt history and Items tabs should be disabled.
f. Any changes made in quantity (received or ordered) or funds in the modal should be
reflected in the table if you click save from the modal.
22. Once you've done all you checking and verifications click save
23. While saving a progress bar should appear
24. If no error was detected, you should be redirected back to parcel.pl
page
25. If an error or warning was detected (like there is an order with 0
items to receive) the save button should be disabled and warnings
are dispayed.
26. prove t/db_dependent/Koha/Acquisition/Fund.t t/db_dependent/Koha/Acquisitoin/Order.t t/db_dependent/Koha/Item.t
Sponsored-by: Virginia Polytechnic Institute and State University
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Set RESTBasicAuth preference to true
3. Get a biblio with an item
4. Make a PUT request to /api/v1/biblios/:biblio_id/items/:item_id with a json body that represents an item to replace
5. Check that the item was modified
6. Sign off
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Set RESTBasicAuth preference to true
3. Get a biblio
4. Make a POST request to /api/v1/biblios/:biblio_id/items with a json body that represents the new item
5. Check that the item is created
6. Sign off
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We were cheating a bit here and expecting a 'debit' to be sent in but a
'line' to be returned.
We should really be sending a debit and returning a debit.. so I've
update the paths schema as such and we're now coercing the
Koha::Account::Line object that's returned by Koha::Account->add_debit
into a Koha::Account::Debit object. Longer term it would be nice to
convert returns from the various Koha::Account methods to their correct
Koha::Account:: objects as apposed to them all being the base ::Line
I've also added some code to catch exceptions that can be thrown by
Koha::Account->add_debit and added the appropriate 400 errors into the
path specs again.
Finally.. I added more unit tests to prove the above
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an endpoint to create a debit for a patron.
Testplan
1. Create a new account debit type (Administration > Debit types)
2. Add a fee with this debit type to a patron’s account via API
3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface
4. Make sure that it is possible to make a payment for this fee
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds two new API endpoints for fetching a patrons credits and
a patrons debits.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an endpoint to list authorities
To test:
1. apply patch
2. enable basic auth
3. call to GET /api/v1/authorities with the following Accept headers:
* application/json
* application/marcxml+xml
* application/marc-in-json
* application/marc
* text/plain
4. notice how data changes with each Accept header
5. prove t/db_dependent/api/v1/authorities.t
6. sign off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Set RESTBasicAuth preference to true
3. Pick an authority to modify, and modify it's marc record
4. Make a PUT 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
5. If content type is other than 'application/json' place the following header in the request 'x-authority-type: <auth type>'
5. Check that the authority was modified
6. Sign off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Despite its title, this patch does a couple more things.
1. The tests are rewritten to cover more things, and also to avoid
deleting all authorities inside the transaction. It is really not
required.
2. It makes the endpoint rely on the already generically implemented
x-koha-override header, which is intended for the same use case as
x-confirm-not-duplicate is for.
3. It changes the return codes to match the coding guidelines [1]
4. Only checks for duplicates if no override passed.
To test:
1. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/authorities.t
=> SUCCESS: Tests pass!
2. Apply this follow-up
3. Repeat 1
=> SUCCESS: Tests pass!
4. Sign off :-D
[1] https://wiki.koha-community.org/wiki/Coding_Guidelines_-_API#SWAGGER3.2.1_POST
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Set RESTBasicAuth preference to true
3. Make a POST request to /api/v1/authorities with one of the following content type header
- application/json
- application/marcxml+xml
- application/marc-in-json
- application/marc
4. If content type is other than application/json, then add the following header to the request: "x-authority-type: <auth type code>"
5. Check that the authority is created
6. Sign off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
