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 patch makes the OAuth/OIDC client pass a `state` parameter with a
CSRF protection token, to be validated back when the flow returns to
Koha.
Ideally, the Mojolicious::Plugin::OAuth2 library should deal with this
implicitly, probably making use of JWT. But as of now, this is the best
way to implement it.
To test:
1. Have a working SSO solution (ktd --sso)
2. Click to login using SSO
=> SUCCESS: Notice a 'state' parameter on the URL, looks like a random
thing
3. When you login, no error is reported
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Users needs anonymous access to OAuth endpoints so that they can
login, and then use authenticated access for other endpoints.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the URL for staff login not point to the `/public`
namespace. The behavior is not changed for the protocol, but as
`/public` requires several settings to be available, it effectively
requires to enable the OPAC, the public API, etc. This patch
diferentiates both to solve the problem.
I've tested following the Wiki instructions to set keycloak [1] using
the *--sso* switch for `ktd` as well [2].
It is important to set the following URLs as allowed redirect in order
to replicate the issue and verify the fix:
http://localhost:8080/api/v1/public/oauth/login/test/opachttp://localhost:8081/api/v1/oauth/login/test/staff
To test:
1. Login into the staff interface using the SSO link:
=> FAIL: Results in a 'Bad redirect URL' error
2. Apply this patch and repeat 1
=> SUCCESS: You get a permission denied error or you just login,
depending on your setup.
[1] https://wiki.koha-community.org/wiki/Testing_SSO
[2] ktd --sso up -d
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
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) Run the following test and make sure all pass:
t/db_dependent/api/v1/biblios.t
t/db_dependent/api/v1/checkouts.t
t/db_dependent/api/v1/return_claims.t
t/db_dependent/Circulation/CalcDateDue.t
t/db_dependent/Circulation/CheckIfIssuedToPatron.t
t/db_dependent/Circulation/dateexpiry.t
t/db_dependent/Circulation/GetPendingOnSiteCheckouts.t
t/db_dependent/Circulation/GetTopIssues.t
t/db_dependent/Circulation_holdsqueue.t
t/db_dependent/Circulation/IsItemIssued.t
t/db_dependent/Circulation/issue.t
t/db_dependent/Circulation/MarkIssueReturned.t
t/db_dependent/Circulation/maxsuspensiondays.t
t/db_dependent/Circulation/ReturnClaims.t
t/db_dependent/Circulation/Returns.t
t/db_dependent/Circulation/SwitchOnSiteCheckouts.t
t/db_dependent/Circulation.t
t/db_dependent/Circulation/TooMany.t
t/db_dependent/Circulation/transferbook.t
t/db_dependent/DecreaseLoanHighHolds.t
t/db_dependent/Holds/DisallowHoldIfItemsAvailable.t
t/db_dependent/HoldsQueue.t
t/db_dependent/Holds/RevertWaitingStatus.t
t/db_dependent/Illrequests.t
t/db_dependent/ILSDI_Services.t
t/db_dependent/Items.t
t/db_dependent/Koha/Account/Line.t
t/db_dependent/Koha/Acquisition/Order.t
t/db_dependent/Koha/Biblio.t
t/db_dependent/Koha/Holds.t
t/db_dependent/Koha/Items.t
t/db_dependent/Koha/Item.t
t/db_dependent/Koha/Object.t
t/db_dependent/Koha/Patrons.t
t/db_dependent/Koha/Plugins/Circulation_hooks.t
t/db_dependent/Koha/Pseudonymization.t
t/db_dependent/Koha/Recalls.t
t/db_dependent/Koha/Recall.t
t/db_dependent/Koha/Template/Plugin/CirculationRules.t
t/db_dependent/Letters/TemplateToolkit.t
t/db_dependent/Members/GetAllIssues.t
t/db_dependent/Members/IssueSlip.t
t/db_dependent/Patron/Borrower_Discharge.t
t/db_dependent/Patron/Borrower_PrevCheckout.t
t/db_dependent/Reserves/GetReserveFee.t
t/db_dependent/Reserves.t
t/db_dependent/rollingloans.t
t/db_dependent/selenium/regressions.t
t/db_dependent/SIP/ILS.t
t/db_dependent/Holds.t
t/db_dependent/Holds/LocalHoldsPriority.t
t/db_dependent/Holds/HoldFulfillmentPolicy.t
t/db_dependent/Holds/HoldItemtypeLimit.t
t/db_dependent/Circulation/transferbook.t
2) Performe one or more checkouts for a patron, making sure
that the circulation rules allows for renewals (for example by
setting an earlier due-date).
3) Log in as this patron in OPAC and make sure the list of
checkouts is displayed correctly, and that renewing an issue
still works.
Sponsored-by: Gothenburg University Library
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch addresses the fact the invalid FK error might differ under
some circumstances. We could try to catch the exception adding another
case, but I think this pattern is cleaner and the authors didn't provide
a fix.
We can discuss it later, as this controller class has several things to
review.
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>
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>
When running against Zebra, this tests fail because it requires the
record to be indexed timely. In theory, a 5 seconds delay should be
enough for the indexer to pick up. But that's not the point of the test,
and we should better just mock the query in this case.
To test:
1. Have ktd launch with zebra:
$ ktd up -d
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/authorities.t
=> FAIL: Tests fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Launch ktd with ES:
$ ktd down
$ ktd --es7 up -d
6. Repeat 2
=> SUCCESS: Tests pass!
7. Sign off :-D
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>
This patch can largely be checked in the code to ensure it makes sense, it
moves a conditional up one level for the two different checks that could prevent holds
To test:
1 - Attempt to place a hold via the REST API with an invalid pickup location
Set pickup location as no in branches to make this easy
2 - Confirm you get an error
3 - Attempt again with header (bug 27760):
x-koha-override: any
4 - Hold is placed
5 - Repeat 1-4 above but with an item that cannot be held
6 - Apply patch
7 - Repeat 1-4 above
8 - Results should be the same
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
This patch introduces a method for filtering out requests that match the
statuses specified on the *ILLHiddenRequestStatuses* system preference.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Illrequests.t
=> SUCCESS: Tests pass!
3. Sign off :-D
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>
When adding or removing eholdings from EBSCO, if an error happens it is
lost and not propagated to the UI.
We were missing a return in the logic, and always returning 200
Test plan:
Do not apply (or revert) bug 33481
Configure EBSCO for ERM and add a package to your holdings
With this patch applied you will get a 500 that is propagated to the UI
Without this patch nothing happens and the user is not aware that
something bad happened
Signed-off-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 adds the status_alias column to the ILLHiddenRequestStatuses sys pref check.
Because requests will have status_alias NULL by default, we also check for that.
Test plan:
Create multiple ILL requests of different backends and place them in different status (NEW, COMP, REQ, etc)
Create multiple ILLSTATUS entries
Add and remove a mix of both status and status_alias codes in ILLHiddenRequestStatuses and refresh the ILL requests page to confirm the result is according to expectation.
Sponsored-by: PTFS Europe
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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>
When we worked on Koha::Biblio::Metadata, we agreed
biblio_metadata.schema would be the sourceof truth when it comes to the
record schema.
This patch acknowledges that, while retaining the fallback to the
syspref.
To test:
1. Apply this patch
2. Run:
$ prove t/db_dependent/api/v1/biblios.t
=> SUCCESS: Tests pass, behavior is unchanged.
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1. Be sure to test on a UNIMARC instance
2. Enable system preferences RESTPublicAPI and RESTPublicAnonymousRequests
3. Create a biblio with some diacritics
4. Restart koha and do not interact with OPAC or the staff interface
(this may change $MARC::File::XML::RecordFormat)
5. Query the public API to retrieve the created biblio in MARCXML. For
instance with cURL:
curl -H 'Accept: application/marcxml+xml' \
http://koha.local/api/v1/public/biblios/<biblionumber>
You should see encoding issues.
6. Apply the patch and restart Koha.
7. Repeat step 5.
You should see no encoding issues.
8. You should also test /api/v1/biblios/<biblionumber> (this one
requires authentication, so cURL might not be the most practical
tool; use your favorite tool for this)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We use another exception now.
Test plan:
Run t/db_dependent/api/v1/patrons.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
We semi-recently introduced error_code into our error object to allow
for translation and code paths for different errors without having to
rely on long description string matches.
This QA follow-up converts the existing match and new 'key' fields
introduced in this patchset to use the updated 'error_code' key.
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>
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>
The spec contains a non-standard definition for the body param. Removing
it from the spec makes us need to handle the 'body' manually in the case
of JSON data.
This patch basically does that. It also changes the uses of
$c->validation, which are discouraged by the
Mojolicious::Plugin::OpenAPI dev/maintainer. I do it to highlight what
we must do in other places and the fact that there's no behavior change.
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/biblios.t \
xt/api.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an exception to stash_embed that is thrown when we
find an x-koha-embed header that we're not expecting.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is using plain `$biblios->to_api` but as of bug 33080, the new
helper should be used instead. This patch fixes that.
To test:
1. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/biblios.t
=> SUCCESS: Tests pass!
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an endpoint to list biblios
To test:
1. apply patch
2. enable basic auth
3. call to GET /api/v1/biblios 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/Koha/Biblios.t t/db_dependent/api/v1/biblios.t
6. sign off
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Hammat Wele <hammat.wele@inlibro.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adapts the other controllers that rely on
add_pagination_headers outside of `objects.search`.
To test:
1. Apply this patchset
2. Run:
$ ktd --shell
$ prove t/db_dependent/api/v1/* \
t/db_dependent/Koha/REST/Plugin/Objects.t \
t/db_dependent/Koha/REST/Plugin/Pagination.t
=> SUCCESS: Tests pass!
3. Sign off :-D
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. Make a POST request to /api/v1/biblios with one of the following content type header
- application/marcxml+xml
- application/marc-in-json
- application/marc
4. Add the following header to the request: "x-framework-id: <framework id>"
5. Check that the biblio is created
6. Sign off
Signed-off-by: Jan Kissig <jkissig@th-wildau.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
DelAuthority doesn't return an error, so the only possible error
conditions are exceptions, that are unknown for now. Removing the error
checking control structure and the 409 error returning, which is
inherited from DelBiblio's call on the biblios endpoint.
It will now just return a 500 in the event of an unhandled internal
error.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Apply patch
2. Set RESTBasicAuth preference to true
3. Get the id of an authority
4. Make a DELETE request to /api/v1/authorities/{authid}
5. Check that the authority was deleted
6. Sign off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch introduces the `api_strings_mapping` method to the
*Koha::Item* class, and makes the API spec for the following routes:
* GET /items
* GET /items/:item_id
* GET /acquisitions/orders
accept the new `+strings` parameter that can be passed through the
`x-koha-embed` header and was introduced by bug 26635. In the case of
/acquisitions/orders, you will need to use
x-koha-embed: items+strings
I introduce it here to highlight the flebility we introduced with bug
26635.
The `api_strings_mapping` method has its roots on the cool
`columns_to_str` method already present. The main differences:
* It is aware of the `public_read_list` for attributes so no hidden
information is exposed.
* Attribute names get mapped for consistency with the API (e.g.
`homebranch` is converted into `home_library_id`, etc).
* The data structure it returns includes information about the source
for the descriptions (e.g. it it is an authorised value, then `type`
will be `av`, and the related category information is returned so
dropdowns and such can be built. The same goes for other types as
`library`, `item_type` and `call_number_source`.
To test:
1. Apply this patch
2. Reload everything
3. Play with your favourite REST tool (e.g. Postman)
4. Try:
GET http://localhost:8081/api/v1/items
x-koha-embed: +strings
=> SUCCESS: You get a list of items, they include the new _strings
structure, and the contents make sense!
5. Repeat with a specific item:
GET http://localhost:8081/api/v1/items/14
x-koha-embed: +strings
=> SUCCESS: It all makes sense!
6. Sign off :-D
Sponsored-by: Virginia Polytechnic Institute and State University
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.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>
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>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the notice codes from 'catalog' to 'catalogue' to be
consistent with the existing codebase.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a catalog concern management page to the staff client
accessible via the cataloging home page and a new 'Pending catalog
concerns' link on the front page.
This includes added the requisit ticket_updates api endpoints and notice
triggers and templates for notifying patrons of changes to their
reported concerns.
Test plan
1) Enable the `OpacCatalogConcerns` system preference
2) Catalog concern management is tied to your users ability to edit the
catalog, `editcatalogue`.
3) Confirm that you can see 'Catalog concerns' listed on the cataloging
home page if you have the `editcatalogue` permission and not if you
do not.
4) Add a new concern as an opac user.
5) Confirm that once a concern is present in the system you see a count
of 'catalog concerns pending' on the intranet main page if you have
the `editcatalogue` permission.
6) Click through either the cataloging home page or pending concerns
link on the main page to view the new concerns management page.
7) Confirm the table displays as one would expect.
8) Confirm clicking on details or the concern title exposes a 'details'
modal with the option to add an update or resolve the concern.
9) Verify that if selecting 'notify' when updateing or resolving a
concern triggers a notice to be sent to the opac user who first
reported the issue.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds basic CRUD API's for the ticket endpoints.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Owen Leonard
Tomas Cohen Arazi
David Cook
Agustin Moyano
David Gustafsson
Kyle M Hall
Nick Clemens
Martin Renvoize
Pedro Amorim
Jonathan Druart
Julian Maurice
Marcel de Rooy