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>
(cherry picked from commit 9afc411a15)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 54c8aa9471)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 3dc9bf900b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 4ce7ce2a15)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit cf94eae1ff)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 749783debf)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 3870b5a068)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 2a8c43f975)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
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>
(cherry picked from commit 69653a281d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
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>
(cherry picked from commit 2d27d02a4d)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
(cherry picked from commit c4cb183ae1)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
(cherry picked from commit 34b704fb0b)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
(cherry picked from commit 252753f84f)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
(cherry picked from commit a8633a5812)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
(cherry picked from commit 1f0cd38d56)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
Without this patch the API driven list of pending orders
on the order receive page was broken.
With the patch, all should be well now.
prove -v t/db_dependent/api/v1/acquisitions_orders.t
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>
* Add GET /illbackends/{id}/statuses
* Change API route to ill/requests
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Use kohaTable requesting the REST api instead of the old KohaTable
Co-authored-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Co-authored-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch renames the header on the biblio API so it is not entirely
tied to MARC, trying to follow the biblio_metadata table generic
approach.
To test:
1. Apply this patch
2. Run:
$ prove t/db_dependent/api/v1/biblios.t
=> SUCCESS: Tests pass
3. You agree with the change?
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Change sounds reasonable. Tests pass before and after patch.
"grep -r "x-marc-schema" *" confirms no occurrences after patch.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 33066: (follow-up) Use KohaTable for LicensesList
There was a mismatch, we can embed the whole vendor object info.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Agustín Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 33066: (follow-up) Embed vendor and retrieve vendor name from the request
It needs "Bug 32923: Allow to embed user_roles for agreements"
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Agustín Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a /public equivilent to the item listing endpoint.
This allows us to search for an item by it's external_id (barcode).
Test plan
1. Apply patch
2. Perform a GET on /api/v1/public/items?external_id=some_barcode
3. Confirm that the above endpoint correctly returns items that should
be visible in the OPAC
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 33146: (QA follow-up) Do not delete all items in test
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 33146: Allow embedding expanded coded values
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 33146: (QA follow-up) Consistency with /biblios/:biblio_id/items
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 33146: (QA follow-up) Make sure public API enabled for tests
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Create an item bundle (see bug 28854 comment 458)
2. Create a biblio with one item and place a hold for this item.
3. Try to add the reserved item to the bundle
You should see a message saying that the item is reserved. Next to
this message should be a button "Ignore holds and add to bundle".
4. Click on the button. There should be a message saying that the item
was added to the bundle.
5. Close the modal window and verify that the item was correctly
added to the bundle
Signed-off-by: Lucas Gass <lucas@bywatersolutiosn.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When trying to add a checked out item to an item bundle, an alert
message will show up, giving the user a chance to return the item
immediately before adding it to the bundle
Test plan:
1. Create an item bundle (see bug 28854 comment 458)
2. Create a biblio with one item and check out this item.
3. Try to add the checked out item to the bundle
You should see a message saying that the item is checked out. Next to
this message should be a button "Check in and add to bundle".
4. Click on the button. There should be a message saying that the item
was added to the bundle.
5. Close the modal window and verify that the item was correctly
returned and added to the bundle
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>
