1. Go to Koha Administration, MARC bibliographic frameworks
2. Edit a framework, find tag 590, edit the $z subfield to use an
authorised value.
3. Do a catalogue search and edit a record using this framework. Edit
590$z and select an authorised value. Save the record.
4. Add the record to your cart.
5. View your cart. Click More Details.
6. Scroll down to the Notes section. Notice the authorised value code is
displayed instead of the description.
7. Apply the patch, restart services.
8. Refresh your cart. Click More Details again if you need to.
9. Scroll down to the Notes section. The description of the authorised
value should now be displayed.
Sponsored-by: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Bug 28734: (follow-up) Use transformMARCXML4XSLT and tests
Confirm the following tests pass:
- t/db_dependent/Koha/Biblio.t
- t/db_dependent/XSLT.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Bug 28734: (QA follow-up) Fix test imports and readability
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Bug 28734: (QA follow-up) Update documentation about function usage
We are now using the function from Koha::Biblio.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Bug 28734: Remove unadvertised changes
1. Using $frameworkcode instead of the default '' is an unadvertised change.
It would make sense to use $frameworkcode, but actually we must remove this parameter and always use the default, as we decided to make the default authoritative.
I would prefer to not introduce this change, just in case..
2. Restore good import (use plurals)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On writing the regression tests, I noticed the CREATE offset was added
to the template. The idea behind passing the offsets is that we can
print information about the lines that got the credit applied. Having
the CREATE offset is meaningless, and (worse) would require users to add
logic to skip it. And all the payment information is already passed in
the 'credit' variable anyway.
This patch filters the credit_offsets by type, leaving the APPLY ones
only.
To test:
1. Apply up to the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Account.t
=> FAIL: 3 offsets, including the CREATE one, boo!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass! Only the two APPLY offsets are returned!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We already had exceptions on the many-to-many links, but we didn't have
them for the middle table. The underlying dbic relations make it clear
which id's are being used for linking. A 'credit' has 'credit_offsets',
a 'debit' has 'debit_offsets'.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The bug here was worse than originally thought. We were calling the
wrong relation too.. we should probably add some exceptions to catch
this, it confuses me every single time!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Being based on _new_from_dbic (discussion on bug 28883), makes the
assignment incorrect:
my @account_offsets = $payment->debit_offsets;
This patch explicitly makes the resultset be assigned as a list by
calling *as_list*.
To test:
1. Have UseEmailReceipts disabled
2. Have a patron with a debt of 6
3. Make a payment of 2
=> SUCCESS: All good
4. Enable UseEmailReceipts
5. Repeat 3
=> FAIL: You get something like:
ERROR PROCESSING TEMPLATE: undef error - The method Koha::Account::Offsets->debit is not covered by tests!
Trace begun at /kohadevbox/koha/Koha/Objects.pm line 595
Koha::Objects::AUTOLOAD('Koha::Account::Offsets=HASH(0x561cbe2ac930)') called at input text line 6
eval {...} at input text line 6
eval {...} at input text line 23
6. Apply this patch
7. Repeat 3
=> SUCCESS: It doesn't explode anymore!
8. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a try/catch block when instantiating plugins. Calling
->new on a plugin eventually triggers a call to ->install (this has
always been like this since bug 7804). If the ->install method is
somehow borked, then the process dies. We need to prevent that, and
report back some error took place. That's what this patch does.
The same happens to the ->upgrade.
To test:
1. Install any plugin you like
2. Restart plack (just in case)
=> SUCCESS: All good
3. Manually change its install method to:
sub install {
die "plugin, die!";
}
4. Run:
$ koha-mysql kohadev
> DELETE FROM plugin_data;
(to make sure there's no __INSTALLED__ entry, do on a safe to delete DB).
5. Point your browser to the plugins-home.pl page
=> FAIL: Boom
6. Apply up to the regression tests
7. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Plugins.t \
t/Koha/Exceptions.t
=> FAIL: Tests fail!
8. Apply this patch
9. Repeat 2
=> SUCCESS: Tests pass!
10. Run:
$ restart_all
11. Repeat 5
=> SUCCESS: The page is not broken
12. Sign off :-D
Note: I used
$ kshell
k$ perl misc/devel/install_plugins.pl
to test as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch introduces two new exceptions:
- Koha::Exceptions::Plugin::InstallDied
- Koha::Exceptions::Plugin::UpgradeDied
Tests are added for their stringification output.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/Koha/Exceptions.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Use additional_report to retrieve patron and biblio's info.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch allows staff patrons to cancel multiple holds in bulk.
To test:
1. Apply this patch
2. restart_all
3. In cataloge go to a book and place many holds
CHECK => Holds table shows a column of checkboxes
4. Play with checkboxes (have some fun ;-P)
CHECK => When you manually check all checkboxes, the checkbox in the
header also gets checked.
=> When you uncheck one of the checkboxes, the one in the header also gets unchecked.
=> If no checkbox is checked and you check the one in the header,
all checkboxes get checked.
=> If there are some checkboxes that are checked and others are
not, when you click on the checkbox in the header all checkboxes get
unchecked.
=> If all checkboxes are checked, when you uncheck the one in the
header, all checkboxes get unchecked.
=> Every time you play with checkboxes, the number in the button
"Cancel selected" changes.
5. Check some of the checkboxes and click on cancel selected.
SUCCESS => A background job gets fired to cancel all selected holds.
=> A message should appear with a link to the job.
6. Wait a few seconds and click on the link
SUCCESS => A message appears with the report of the execution of the
background job.
7. Grab a patron and search to hold
8. Select multiple biblios and click on "place hold for <patron>"
CHECK => After holds are confirmed, multiple holds table are shown.. one for
each record. Checkboxes work exactly the same as before, but scoped
for each individual table. Checkboxes from one table will not affect
checkboxes from other tables.
9. Repeat steps 4 to 6.
10. Check In some of the items so the get in Waiting state.
11. Update expirationdate os some of those holds and set it to
ReservesMaxPickUpDelay + 1 days earlier
NOTE => ReservesMaxPickUpDelay = 7 days by default, so sql syntax to update would be
=> update reserves set expirationdate = date_sub(expirationdate, interval 8 day) where reserve_id in (...)
12. Repeat steps 4 to 6 but in waitingreserves.pl, in both tabs.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 23678: (QA follow-up) Add missing template filter
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 23678: (QA follow-up) Add missing filters
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 23678: (QA follow-up) Use correct indentation
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
JD amended patch: also Koha/BackgroundJob/BatchCancelHold.pm
JD Amended patch: Full rebase and adjustements made on top of bug 26080.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes the mapping so it is more readable, and also allows
adding things there more easily, like allowing to add code => class
mappings from plugins, when time comes.
To test:
1. Just verify things still work
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(Patch extracted from bug 28445 to make it reusable for bug 23678)
We already had the need for that, when bibliographic records are
modified in batch we wanted to add a "Add to list" feature, and so pass
a list of lists/virtual shelves to the template.
Here (in 28445) we will want to pass the infos of the items that have been modified
to display a table.
Test plan:
0. Create at least one list (virtual shelf)
1. batch update biblios
2. Go to the job detail
3. Notice that dropdown list to add the record to a list
=> No regression found!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same as the first patch, for authorities
Test plan:
Delete authority records using the batch record deletion tool
Confirm that the job is now delegated to the task queue and that
everything else is working as before
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch takes advantage of the task queue to delegate the batch
delete biblios tool.
Test plan:
Delete bibliographic records using the batch record deletion tool
Confirm that the job is now delegated to the task queue and that
everything else is working as before
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the Koha::OAuth library use the new validation method
To test:
1. In master, enable RESTOAuth2ClientCredentials and have your
superlibrarian patron a client_id/secret pair generated
2. Use Postman to gain an access token with the client_id/secret pair
=> SUCCESS: This works in Koha
3. Use the access token to GET /api/v1/patrons
=> SUCCESS: It works
4. Apply this patchset up to the regression tests
5. Run:
$ updatedatabase
$ koha-plack --restart kohadev
=> SUCCESS: All good
6. Repeat 2
=> FAIL: You get an error trying to acquire an access token. Boo
7. Run:
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> FAIL: Tests fail!
8. Apply this patch
9. Run:
$ koha-plack --restart kohadev
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> SUCCESS: Tests pass!
10. Repeat 2
=> SUCCESS: Your original client_id/secret pair works!
11. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch refactors the Koha::ApiKey class so:
- It encrypts the generated secret
- Allows accessing the plain text secret only immediately after the key
creation (this implies that it won't be accessible if the key is
fetched from the DB).
- It implements an allow list for attributes, that are not read only.
Changing any other of them will make ->store throw an exception.
- A method for validating plain text secrets against the encrypted one
is added.
- A method for accessing the plain text secret is added. Returns undef
if the object is not 'fresh'.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/ApiKey.t
=> SUCCESS: Tests pass! Expected behavior is confirmed
3. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This bug adds a system preference to control ordering of facets and
adds the control to both Zebra and Elasticsearch
To test:
1 - Have a koha that can use both Zebra and ES
2 - Set 'displayFacetCount' to true
3 - Search in ES and Zebra
4 - Note facets in Zebra sorted alphabetically, ES by usage
5 - Apply patch, updatedatabase
6 - Search in ES and Zebra, facets are alphabetically sorted in both
7 - Find new syspref FacetOrder and set to 'by usage'
8 - Search in both engines, facets sorted by usage
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
- Create a biblio with title like "osteuropa:" or "osteuropa!"
- Go the this biblio detail pages (cgi-bin/koha/catalogue/detail.pl)
=> Error
- Apply bug 28316 and this one
- test again
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
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: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the exceptions thrown by Koha::Email to include the
parameter that failed email validation and then updates the failure code
to include this parameter and finally display this field in the template.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To ease testing and future changes if needed.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a new dependency, Email::Address. It is used in
Koha::Email to replace the current use of Email::Valid, which proved to
be problematic when it comes to UTF-8 characters.
Email::Address provides suitable regexes that -when used- keep our
tests passing, but also deal better with UTF-8 data.
To test:
1. Apply the regression tests patch
2. Notice the only change is that it tweaks a couple addresses so they
contain umlauts and also have the "Description <address>" format that
is used when sending carts.
3. Run:
$ kshell
k$ prove t/Koha/Email.t
=> FAIL: Tests fail! Things die because Email::Valid doesn't like the
from we passed.
4. Run:
$ sudo apt install libemail-address-perl
5. Apply this patch
6. Repeat 3
=> SUCCESS: Tests pass!
7. Try what is described in comment 1
=> SUCCESS: Things are back to normal
8. Sign off :-D
9. Send cookies
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This commit sorts metadata by key prior to preparing a notice with it
Test plan:
- Do not apply patch
- Create a report with the following SQL:
SELECT * FROM message_queue;
- Create an ILL request with plenty of metadata
- Go to "Manage request"
- Send a notice to a patron
- Run the report created earlier
=> TEST:
- Observe that the metadata is in random order
- Apply the patch
- Create an ILL request with plenty of metadata
- Go to "Manage request"
- Send a notice to a patron
- Run the report created earlier
=> TEST:
- Observe that the metadata is now sorted alphabetically by key
Signed-off-by: Jill Tivey <Jill.Tivey@sasa.gov.scot>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes an active request's backend and initiates the
migration on that request, rather than creating another and migrating
that.
The majority of the work to accomplish this bug is being carried out in
the backends, since Koha delegates migrations to them.
Signed-off-by: Barry Cannon <bc@interleaf.ie>
Signed-off-by: Assumpta Byrne <abyrne@ait.ie>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 22440 will rewrite the route and make it even more efficient by
prefetching the related data instead of performing several queries in
loops.
In the meantime, we can make this controller perform better with a
simple intervention: load backends once, and use the
$request->_backend() setter to pre-set it before using the objects.
To test:
1. Perform any usual ILL requests listing, try having several
=> FAIL: Notice it takes a weird amount of time to load
2. Apply this patch
3. Restart all
4. Repeat 1
=> SUCCESS: It feels fast enough!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
With all the work that's gone into improving the internal
_clean_search_term method I feel we should expose it publically as it's
going to be more widely helpful
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
if QueryAutoTruncate enabled we will have any special operators ruined
for example: "test [6 TO 7]" will be converted to "test* [6* TO* 7]"
so no reason to keep ranges when QueryAutoTruncate set to "enabled"
1) enable QueryAutoTruncate at your sysprefs.
2) perform a search using range, for example: "[1999 TO 2020]",
it shouldn't work the way it's supposed to.
3) apply the patch.
4) perform the same search with range, ensure that it works correctly.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch ensures that the behavior with
QueryRegexEscapeOptions set to values other than
"Escape" still will works as expected.
It does so by storing the contents of regexes
before escaping special characters and
then restores the contents of regexes back to how
it was before, ensuring that searching with regex is possible.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently having exclamation sign at the end of the query makes ES
search fail, and when you try to search for a book that has exclamation
sign in the tittle (something like "Words! words") won't show results
correctly as it tries to negate everything that is after exclamation
sign, making it impossible to search for books that have in in the title
This patch escapes exclamation signs if it's at the end of the query or
has a space after it, resolving both of the issues listed above.
To reproduce:
1) with ES enabled, search for the book with title that contains
exclamation sight at the end, like "book!", this search should result
in error.
2) do another search, but this time find/prepare beforehand book with a
title that has exclamation sign with a space after it,
e.g "exclamation! sign", it shouldn't find it as ES treats everything
after that exclamation sign as negation.
2) apply the patch.
3) perform searches from the steep one and two again.
Search from step one should no longer fail, while search from the step
two should find that book.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch screens square and curly brackets which have no special
language meaning.
To reproduce:
1) using ES, search for the book with title that contains
square and/or curly brackets, like "book [second edition]", which will
result in error.
2) apply the patch.
3) search for that book again, ensure that it works now.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently searches like: "book:", ":book" and "host-item:test:n"
cause internal server errors.
This patch adds additional regexes that remove the colons at the start
and end of the query, and another regex that screens all follow-up
colons that go after the first colon to avoid errors when searching for
"host-item:test:n".
To reproduce:
1) using ES, search for the book with title that contains
semicolon at the start or at the end of the line, separated with spaces,
this should cause internal server error.
2) try doing the same with something like "host-item:test:n", it should
result in error as well.
3) apply the patch.
4) repeat steps 1-2, ensure that it works now.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes the code from the search scripts into QueryBuilder
modules.
To test:
1 - Have a library group defined as a search group for both staff and opac
2 - Search on staff client and opac with that group limit and a single branch limit
3 - Note your results/counts
4 - Note the visuals of the search description
5 - Apply patch
6 - Repeat searches
7 - All should work as before
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Use of uninitialized value in subroutine entry at /usr/share/koha/lib/Koha/Plugins/Base.pm line 182.
Test Plan:
1) Install the Kitchen Sink plugin ( it does not have a max versio defined )
2) Note the warning in your logs
3) Apply this patch
4) Restart all the things
5) No warning!
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds get_column to ensure we are returning a string value of
a field rather than accidentally triggering a relationship accessor.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The goal is to be able to build a database handler (dbh) and to execute
queries without loading unnecessary stuff. This will be useful to reduce
memory usage of daemons that need to check the database
periodically
The patch provides a new method Koha::Database::dbh which returns a
database handler without loading the DBIx::Class schema. This method is
also used by DBIx::Class, so whether you use DBI or DBIx::Class, the
same method is used to initialize the connection.
The patch also moves some code in order to avoid loading C4::Context:
- C4::Context::timezone moves to Koha::Config
- C4::Context::db_scheme2dbi moves to Koha::Database
To measure memory usage I used the following commands:
* before the patch:
perl -MKoha::Database \
-E 'Koha::Database->schema->storage->dbh->do("select 1");' \
-E '$|=1; say $$; sleep 2' \
| while read pid; do ps -p $pid -o rss=; done
* after the patch:
perl -MKoha::Database \
-E 'Koha::Database->dbh->do("select 1");' \
-E '$|=1; say $$; sleep 2' \
| while read pid; do ps -p $pid -o rss=; done
It will give you the RSS (Resident Set Size) of the perl process in kB
What I get:
* before the patch: between 96.9MB and 97.2MB
* after the patch: between 17.8MB and 18.2MB
Note that if a timezone is configured (either from $KOHA_CONF or
TZ environment variable), Koha will load DateTime::Timezone to check if
it's valid, and it increases RSS to 36MB
Another interesting metric is the number of modules loaded:
* before the patch:
perl -MKoha::Database \
-E 'Koha::Database->schema->storage->dbh;' \
-E 'say scalar keys %INC'
Result: 567
* after the patch:
perl -MKoha::Database \
-E 'Koha::Database->dbh;' \
-E 'say scalar keys %INC'
Result: 51
Test plan:
1. Apply the patch & restart starman
2. Make sure Koha is still ok (ie. can access the database, does not
have encoding issues, ...)
3. Run the tests in t/Context.t, t/Koha/Config.t,
t/db_dependent/Koha/Database.t, t/timezones.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds 'can_be_blank => 0' for the rentaldiscount rule to prevent
storing blank values in the database
Additionally, if there is no charge we do not need to check for a discount
and can simply return
To test:
1 - Set rental discount to "" to a rule in circulation rules
2 - Checkout an item that will follow this rule
3 - Check the intranet log:
[WARN] Argument "" isn't numeric in subtraction (-) at /kohadevbox/koha/C4/Circulation.pm line 3385.
4 - Apply patch and restart all
5 - Update database
6 - Set the rule to "" again
7 - Check the DB, no rule is stored
SELECT * FROM circulation_rules WHERE rule_name = 'rentaldiscount';
8 - Checkout the item again
9 - No warns in log
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is existing error message in the code stating:
"Unable to understand your search query, please rephrase and try again."
which fits perfectly but because it looks for "ParseException" in the
warning output it doesn't show up on this page as it's actually
"parse_exception".
This patch makes that it's also checked if "parse_exception" is present
in the warning output.
Side note:
"ParseException" reaction code was added here:
e0f6c4dc Bug 12478: improve error reporting a bit
Search::Elasticsearch seems propagates clean ES JSON answer,
and in current ES version inside of $@ it contains "parse_exception"
string in dumped JSON answer ("'type' => 'parse_exception'").
Old seeked phrase "ParseException" wasn't reproduced, only in ES logs
("Caused by: org.apache.lucene.queryparser.classic.ParseException:
Cannot parse ..."). Check for both phrases won't complicate future
changes, but this note added for reference and code cleanup if needed.
To reproduce:
1) using ES search for something like "// ^ ! { } [ ] .. , <>" that
will for sure break the syntax of ES.
2) after the search query fails note that the error is
"Unable to perform your search. Please try again."
3) apply the patch
4) search for the same thing again
5) error message should be "Unable to understand your search query,
please rephrase and try again." now.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the cni/Control-number-identifier index to enable
searches to use the 003 field.
Test plan
1/ Apply patch
2/ Re-index using updated configurations
3/ Confirm cni:number searches yield the expected results
4/ Signoff
Split-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Pasi Kallinen <pasi.kallinen@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We always had some mapping because of the DB vs. API object definition discrepancies. But bug 25260 revamps the reserves table, and it is a perfect match. It highlights this edge case: if no mapping defined, then and undef from_api_mapping is generated (as opposed to an empty hashref) and this leads to errors in the query translation from the API.
This patch makes a small change so this method always returns an empty
hashref.
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Object.t
=> FAIL: Test fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD amended patch: remove uneeded commented lines
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In itemsearch form, there are several filters build with authorized values.
There values should be sorted by description.
Test plan :
1) Create several values and descriptions in authorized values LOC
2) Go to itemsearch
3) See filter by location sorts on description and not on value
Seems change in search_by_marc_field can not be tested in interface
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
'Can't locate object method "_new_from_dbic" via package "Koha::Linktracker" (perhaps you forgot to load "Koha::Linktracker"?) at /kohadevbox/koha/Koha/Object.pm line 334.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
* C4/Items.pm
- Koha::Biblios not used
* Koha/Item.pm
- Koha::Item->orders must return an empty set if no order attached
- no_triggers should be passed to other update calls
* Item.t
- No need to build a fund
- Add new test to test Koha::Item->orders when no order attached
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>