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 clears the JWT cookie during auth kick out (ie
when a web user navigates from the self-check out/in to
the rest of Koha).
Test plan:
0. Apply patch and koha-plack --reload kohadev
1. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
2. Log in as the "koha" user
3. In another tab, go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
4. Go to http://localhost:8080/cgi-bin/koha/opac-search.pl?idx=&q=a&weight_search=1
5. Note that you are prompted to "Log in to your account" via the normal Koha prompt
6. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
7. Note that you are prompted to "Log in to your account" within the "Self checkout system",
and note that your self-checkout session for the "koha" user has *not* persisted like
it did before the patch was applied
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch avoids generating CSRF tokens unless the csrf-token.inc file
is included in the template.
Passed token doesn't need HTML escaped. The docs for WWW::CSRF state:
The returned CSRF token is in a text-only form suitable for inserting into a HTML form without further escaping (assuming you did not send in strange things to the Time option).
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It is possible inject raw HTML into the "Back to search results" link by leading the user to a search with specially crafted URL.
For example, using the demo instance:
1. Visit https://koha.adminkuhn.ch/cgi-bin/koha/opac-search.pl?idx=&q=test&weight_search=1&%22%3Etest%3Ca%20foo=%22
2. Refresh the page (for some reason, "back to results" doesn't appear unless I do that at least once).
3. Click any result.
Note that the result page now contains:
<a href="opac-search.pl?idx=&q=test&weight_search=1&">test<a foo=%22" title="...
i.e. `">test<a ...` was successfully injected into the HTML.
I'm attaching a quick patch I've used to patch up our instance. It just indiscriminately URI-escapes all parameter keys. I didn't decode them back since as far as I understand all valid keys do not contain special characters.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Test plan would have been nioe.
Tested by changing MAX_AGE with suggestions.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This change adds a CSRF token to the Content Management pages
at additional-contents.pl.
Test plan:
0. Apply patch
1. koha-plack --restart kohadev
2. Try to add "News", "HTML customizations", and "Pages".
3. Try to delete these new content entries
4. Note that you were successful in your endeavours
JD amended patch: remove empty line removal (no need to create
unecessary conflicts)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Run t/Output.t
Run t/db_dependent/Auth.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Split out from bug 22990 as requested.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) prove t/db_dependent/TestBuilder.t
2) Note tests fail
3) Apply this patch
4) Run updatedatabase.pl
5) Update the schema files ( alias 'dbic' can be used in
koha-testing-docker )
6) prove t/db_dependent/TestBuilder.t
7) Tests now pass!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1) Run the updated SIP-related unit test *without* having applied
the other patch from this bug report -- it should fail:
$ prove t/db_dependent/SIP/ILS.t
2) Apply the patch that fixes C4/SIP/ILS/Transaction/Renew.pm
3) Re-run the unit test -- it should pass.
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In Koha 23.05, we lost the ability to renew an item via SIP2.
The relevant commit is ddc2906b77 from Bug 31735, where the
file C4/SIP/ILS/Transaction/Renew.pm was modified to no longer
pass an unblessed $patron hash to C4::Circulation::AddIssue()
This patch fixes that.
Test plan:
1) Using the SIP emulator, check out an item to a patron, then
try to renew it. Example commands for a KTD instance:
$ misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m checkout --patron koha --item 3999900000001
$ misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m renew --patron koha --item 3999900000001
Notice that the second command will fail!
2) Apply this patch.
3) Repeat the 2nd command -- this time the renewal should work.
4) Run the SIP-related unit tests, they should all pass:
$ prove t/db_dependent/SIP/
t/db_dependent/SIP/ILS.t .......... ok
t/db_dependent/SIP/Message.t ...... ok
t/db_dependent/SIP/Patron.t ....... ok
t/db_dependent/SIP/SIPServer.t .... ok
t/db_dependent/SIP/Transaction.t .. ok
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) Generate the holds queue
2) Load the holds queue viewer page
3) Apply this patch
4) Restart all the things!
5) Reload the page
6) Note nothing has changed
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
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>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Lets use 'type' definitions at the datatables settings level instead
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If we have filters on top of column on a table that is using the DT REST API wrapper,
we cannot filter on date using formatted dates.
This was done for "date of birth" for bug 32505.
Here we want to provide a generic approach.
Note that we cannot use what has been done on bug 22440 in some cases
(when we don't write the thead DOM directly but rely on DataTables
constructor, for instance bug 33568). The data- attributes are not
passed by DT.
Test plan:
On top of 33568, filter date columns using the full version of the
formatted date
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Email::Sender::Transport::SMTP::Persistent is part of the Email::Sender
distribution, and a git diff on the repository doesn't show any
difference.
The patch author just took the number from MetaCPAN.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Removes the unneded new form element as we have one big form for the whole page.
This should fix the situation where only the prices and information
of the first selected record carreid over into the order.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a first step towards more consistency and possibly supporting
multiple input formats as well in the future. It marks all input fields
for monetary values, such as prices, replacement prices etc. with a class
that is linked to a check for number format with the jQuery Validator plugin.
To test:
For any input field to test, try adding various false entries, like "abc" or "1,00".
It should only accept inputs with decimal dot, like: "1.00"
0) Apply patch, restart_all
1) Suggestion
* Add a new suggestion in the staff interface
* Test: price input field at the bottom of the form.
* Accept the suggestion
2) Order form
* Create a new basket
* Create an order line from an existing record
* Test: list price, replacement price, and actual price.
* Check the checkbox for uncertain price before you save
3) Uncertain prices
* Go to the uncertain prices page for this vendor
* Test: price field
Note: this form does its own validation, but the change should not change behaviour for now
* Resolve the uncertain price
* Close order
4) Receive shipment
* Test: Shipping cost
5) Receive the order
* Test: replacement price, actual price
* Check checkbox for price in foreign currency
* Test: price in foreign currency
* Receive order line
6) Invoice summary
* Finish receiving
* Test: shipping cost
* Test: invoice adjustments: amount in the form for the first entry, amount in the table after adding it
7) Merging invoices
* Receive another shipment and create and invoice
* Go to invoices and search all
* Check the 2 entries for merging
* Test: shipping cost
8) Adding orders from a staged/new file
* Export some records using the cart or list
* Create a new basket
* Order from new file
* Import your file, ignore item records
* Test: price and replacement price
+ Bonus: also test with items, test plan and file from bug 22802 are really helpful here
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is a first step towards more consistency and possibly supporting
multiple input formats as well in the future. It allows us to mark all
input fields for monetary values, such as prices, replacement prices,
fees etc. with a class that is linked to a check for the 'number' format
in the jQuery Validator plugin.
This is the base patch that does nothing by itself, please see
test plan in second patch.
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Resolve:
Use of uninitialized value in hash element at /usr/share/koha/C4/Letters.pm line 1472.
Use of uninitialized value in hash element at /usr/share/koha/C4/Letters.pm line 1473.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
As described in bug 30013, some outgoing SMTP services ( such as Gmail ) do not like Koha's current behavior of initiating a new connection for each email sent. If we switch from Email::Sender::Transport::SMTP to Email::Sender::Transport::SMTP::Persistent and store the object for the duration of the message queue processing, this should solve that issue.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If you import a record, then create an authority record using the automatic linker, it closes the biblio record. The problem occures when a record is edited in a new tab.
To recreate:
1. Import the example records
1.1. Download the example records
1.2. Go to Cataloging > Stage records for import
1.3. Choose the downloaded file
1.4. Click Upload file
1.5. Click Stage for import
1.6. Click View batch
1.7. Click Import this batch into the catalog
1.8. Click View detail of the enqueued job
1.9. Click Manage imported batch
Correct behaviour:
2. In another tab, search for one of the records (for example, Fafounet)
3. Click Edit > Edit record
4. Go to field 100
5. Click Link authorities automatically
--> It should say 100 - No matching authority found.
6. Click the plus sign next to 100
7. Fill out the mandatory fields by clinking in the text fields (000, 003, 005, 008, 040), field 100 should already be filled
8. Click 'Save'
--> Authority number is added in 100 and you get to stay in the record for more edits if needed
Incorrect behaviour:
9. Go back to the imported batch tab
10. Click Edit next to the second title (the one by Paventi, Eza)
11. Redo steps 4 to 8
--> Record is closedclear :(
The behaviour should be the same, stay in the bibliographic record until it is saved.
12. Apply the patch
13. Redo step 9, 10, 4
14. Edit field 100, Type 'Paventi Test 2'
15. Redo step 5 to 8
--> Authority number is added in 100 and you get to stay in the record for more edits if needed
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a patron has no valid email address then a warning message appears in the logs when saving:
"Use of uninitialized value $email in string ne at /kohadevbox/koha/Koha/Patron.pm line 1445."
This patch fixes that error by removing an unnescessary string ne
Test plan:
1) Create/choose a patron with no email addresses
2) On the patron record in the page section for Contact information, click edit
3) Now click save
4) The warning above should appear in the logs
5) Apply patch
6) Repeat steps 2 and 3
7) The warning should no longer appear
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 32257 changed the page structure slightly to fix a display
issue with the labels. This resulted in a broken selector in the
function for displaying the checkboxes for deleting/emptying a
certain patron field.
To test:
* Go to Tools > Batch patron modifications
* Enter some cardnumbers or borrowernumbers
* On the batch patron edit form, verify that the checkboxes
behind each input field are missing
* Apply patch
* Verify the checkboxes reappeared
* Verify that for mandatory fields the checkbox is locked
* Make some batch edits and verify the checkboxes work as
intended
Signed-off-by: Lisette Scheer <lisette.scheer@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We need to drop the embed part of the args we pass to biblioitem else we end
up with some very strange behaviours on the acquisitions endpoint.
Signed-off-by: Silvia Meakins <smeakins@eso.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We're exposing biblio (and thus biblioitem) to the public API now and as
such we need to explisitely list which fields to include in the response
when called on the public api.
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 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>
44 'c|confirm' => \$confirm,
46 'm|matchpoint=s' => \$matchpoint,
The POD is wrong.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a <span> around the text "Item(s)" in the template for
the MARC detail page in the staff interface. Without the span the
translation tool can't detect the string.
To test, apply the patch and update a translation, e.g. fr-FR:
> cd misc/translator
> perl translate update fr-FR
- Open the corresponding .po file, in this case
misc/translator/po/fr-FR-staff-prog.po
- Confirm that the string is now in the .po file for translation. You
should find these lines:
koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/MARCdetail.tt:146
c-format
msgid "Item(s)"
msgstr "Exemplaire(s)"
I found that the translation was already populated. Install the updated
po file:
> perl translate install fr-FR
Test the MARC detail page in your translated language to confirm that
the string is correct.
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
