This patch fixes the logic in a condition to address the fact that
permissions are not checked for plugins. This was due to bad parenthesis
pairing and the lack of good tests for this.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/REST/Plugin/PluginRoutes.t
=> FAIL: Tests fail because of bad logic
3. Apply this patch
4. Repeat (2)
=> SUCCESS: Tests pass!
5. Verify the tests cover the use cases that are needed:
- Anonymous access
- Real user with wrong permissions (parameters => 1)
- Real user with right permissions (borrowers => 1)
=> SUCCESS: Needed use cases so we catch any regression are found
6. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Doing the same change as previously (renaming biblionumber), but fixing
at the same the record fetch. If (theoretically) an authority is passed
without a record, it would have fetched a biblio record.
Test plan:
You need Elasticsearch here.
Replaced this line in AddAuthority:
$indexer->index_records( $authid, "specialUpdate", "authorityserver", $record );
by
$indexer->index_records( $authid, "specialUpdate", "authorityserver", undef );
And updated an authority record. Check if you can search for the change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD amended patch: remove trailing whitespace
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
ModZebra:
The name is very misleading: we can index authid's too here.
And yes, it should not be in C4/Biblio too ;) A first step..
Adding the same change here in Koha/SearchEngine/Zebra/Indexer.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is analogous to 26522, we shoudl skip record that cannot be retrieved for indexing
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: Bob Bennhoff <bbennhoff@clicweb.org>
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: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When batch editing, 2 reindex calls are sent to ES/Zebra.
We can easily avoid that reusing the skip_modzebra_update (renamed skip_record_index)
Additionally we should only send one request for biblio, and we should
only do it if we succeed
As the whole batch mod is in a transaction it is possible to fail in which case
Zebra queue is reset, but ES indexes have already been set
In addition to the skip param this patchset moves Zebra and Elasticsearch calls to
Indexer modules and introduces a generic Koha::SearchEngine::Indexer so that we don't
need to check the engine when calling for index
The new index_records routine takes an array so that we can reduce the calls to
the ES server.
The index_records routine for Zebra loops over ModZebra to avoid affecting current behaviour
Test plan:
General tests, under both search engines:
1 - Add a biblio and confirm it is searchable
2 - Edit the biblio and confirm changes are searchable
3 - Add an item, confirm it is searchable
4 - Delete an item, confirm it is not searchable
5 - Delete a biblio, confirm it is not searchable
6 - Add an authority and confirm it is searchable
7 - Delete an authority and confirm it is not searchable
Batch mod tests, under both search engines
1 - Have a bib with several items, none marked 'not for loan'
2 - Do a staff search that returns this biblio
3 - Items show as available
4 - Click on title to go to details page
5 - Edit->Item in a batch
6 - Set the not for loan status for all items
7 - Repeat your search
8 - Items show as not for loan
9 - Test batch deleting items
a - Test with a list of items, not deleting bibs
b - Test with a list of items, deleting bibs if no items remain where all items are only item on a biblio:
SELECT MAX(barcode) FROM items GROUP BY biblionumber HAVING COUNT(barcode) IN (1)
c - Test with a list of items, deleting bibs if no items remain where some items are the only item on a biblio:
SELECT MAX(barcode) FROM items GROUP BY biblionumber HAVING COUNT(barcode) IN (1,2)
10 - Confirm records are update/deleted as appropriate
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Plugin dirs defined in koha-conf.xml are added to @INC in order to compile perl code.
Looks like with plack those dirs are added several times.
This may lead to an error "INCLUDE_PATH exceeds 64 directories".
This bug was identified with Carrousel plugin : https://inlibro.com/instructions-carrousel/
Test plan :
1) Enable plack and plugins
2) Look at page about.pl : @INC contains one plugin dir 'var/lib/plugins'
3) Install plugin KitchenSink : https://github.com/bywatersolutions/koha-plugin-kitchen-sink
4) Dont apply patch
5) Use configure on KitchenSink
6) Look at page about.pl : @INC contains server plugin dir 'var/lib/plugins'
7) Apply patch and restart plack
8) Use configure on KitchenSink
9) Look at page about.pl : @INC contains one plugin dir 'var/lib/plugins'
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>
Returns from Koha::Item calls were stored in temporary variables
called $item. Unfortunately they occur in routines already with
an $item variable holding a lineitem and hide that variable although
only required for two lines of code. An error occurs if girfield
is called on the wrong variable. Renamed all three occurences
of $item to $kitem to avoid the error
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently Item->store indexes the record before the DB update - that is wrong
To test:
1 - Find/create a bib with no items
2 - add an item with barcode "abc123"
3 - do a general keyword search for "abc123," see your bib is not in the results
4 - perform a search that includes your bib in the results, confirm it shows as having no items
5 - click through to bib details, confirm it shows your item here
6 - edit and save your item
7 - confirm barcode is now searchable
8 - apply patches
9 - Add a new item "cde456"
10 - Confirm it returns in searches
11 - Edit 'cde456' and change barcode to 'fgh789'
12 - Confirm the new abrcode is searchable
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Fix fields order
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - Have some records with uncertain dates in the 008
19uu, 195u, etc.
2 - Index them in Elasticsearch
3 - Do a search that will return them
4 - Sort results by publication/copyright date
5 - Note odd results
6 - Apply patch
7 - Reindex
8 - Sorting should be improved
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a "year" search field type. Fields with this type will only
retain values that looks like years, so invalid values such as
whitespace or word characters will not be indexed.
This for instance improves the behaviour when sorting by
"date-of-publication". If all values are indexed, records with
junk data instead of valid years will appear first among the search
results, drowning out more relevant hits. If assigning this field
the "year" type these records will instead always appear last,
regarless of sort order.
To test:
1) Have at least two biblios, one with a valid year in 008 (pos 7-10)
and another with an invalid one ("uuuu" for example)
2) Perform a wildcard search (*) and sort results by publication date.
3) The record with invalid year of pulication in 008 should appear first
4) Apply patch and run database updates
5) Reindex ElasticSearch
6) Perform the same search as in 2)
7) The record with the invalid year should now appear last
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes Koha::Item->store call $self->SUPER::store before
calling the hook, so things like the itemnumber (AUTO_INCREMENT field)
are available to the plugin hook.
It does so by storing the output on a temporary variable, to keep the
current behaviour of just returning the output from SUPER::store.
To test:
1. Apply the regression tests patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Biblio_and_Items_plugin_hooks.t \
t/db_dependent/Koha/Item.t \
t/db_dependent/Koha/Items.t
=> FAIL: the hooks tests fail. Item.t hasn't been altered so should pass
3. Apply this patch
4. Repeat 2.
=> SUCCESS: Tests pass! Item.t as well! (i.e. no behaviour change)
5. Sign off :-D
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>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Using MySQL 8:
t/db_dependent/Koha/Acquisition/Order.t .. 10/11 No method count found for Koha::Acquisition::Orders DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Incorrect DATE value: '0000-00-00' [for Statement "SELECT COUNT( * ) FROM `aqorders` `me` WHERE ( ( ( `datecancellationprinted` IS NULL OR `datecancellationprinted` = ? ) AND `ordernumber` IN ( ?, ?, ? ) ) )" with ParamValues: 0='0000-00-00', 1=23, 2=24, 3=25] at /kohadevbox/koha/Koha/Objects.pm line 597
We must remove the comparison with 0000-00-00
Highlighted by bug 23166.
I wanted to provide a DB rev but we (obviously) cannot:
MySQL [koha_kohadev]> UPDATE aqorders SET datecancellationprinted=NULL WHERE datecancellationprinted="0000-00-00";
ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'datecancellationprinted' at row 1
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch:
* reverts changes on misc/admin/set_password.pl
* makes category param mandatory for AuthUtils::is_valid_password and AuthUtils::generate_password
* changes onboarding.pl to set category param in AuthUtils::is_valid_password
* Completes t/db_dependent/AuthUtils.t and drops t/AuthUtils.t
* Removes offending <input type="number"/> and replaces it by <input type="text" inputmode="numeric" pattern="[0-9]*"/>
https://bugs.koha-community.org/show_bug.cgi?id=23826
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Ease readability
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
https://bugs.koha-community.org/show_bug.cgi?id=23826
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the capability to override minPasswordLenth and RequireStrongPassword settings by category
To test:
1. koha-shell kohadev
2. koha-mysql kohadev
3. drop database koha_kohadev;
4. create database koha_kohadev;
5. go to admin page and start webinstaller. There continue the steps until onboarding.
6. reach step 3 of onboarding and create a new administrator patron
CHECH => Password control woks as normal (Minimum length 3 and strong required)
7. finish Koha installation and enter admin with your new administrator
8. set minPasswordLength to 3 and RequireStrongPassword to “Don’t require”
9. Create a new category (CAT2 from now on.. CAT1 is the category you made in onboarding process) and set minimum password length to 8 and require strong password
10. Create two new patrons, one with CAT1(patron1) and one with CAT2 (patron2)
CHECK => In both cases, try different combinations of length and strength. For patron1 the only requirement is to have 3 letters, but for patron2 the minimum length will be 8 and will require strong password.
CHECK => Try changing patron category before saving. Password requirements will change with category change.
11. Edit CAT1 and set minimum password length to 5
12. Go to patron1 details page, and change password.
CHECH => Now password minimum length is 5, but still it doesn’t require strong password
13. Edit CAT1, leave blank minimum password length and set require strong password to yes.
14. Go to patron1 details page, and change password.
CHECH => Password minimum length is back to 3, but now strong password is required
15. Set minimum password length in CAT2 to 12.
16. Go to patron2 details page, and click to fill a random generated password
CHECK => generated password should be 12 characters length
17. Set PatronSelfRegistration to Allow in admin settings
18. Go to OPAC and fill self registration from.
CHECK => Play with patron category. For each change in category, password requirements are modified.
CHECK => Set CAT1 as patron category, set ‘aA1’ as password (or another valid password for CAT1) and before hitting submit button, change to CAT2. Form should enter invalid state, and CAT2 password requirements should be displayed as error in password input.
19. Create a patron for CAT1 and another for CAT2, leaving password blank
CHECK => For CAT1’s patron, generated password length is 8 (minimum length for generated passwords), but for CAT2’s patron should be 12
20. In admin set PatronSelfRegistrationVerifyByEmail to require
21. Fill self registration form again with CAT2 as category
CHECK => Password requirements works as previous case.
22. Leave password blank and click submit
23. select * from message_queue;
24. Copy the link in the message and paste it in OPAC
CHECH => Generated password is 12 characters long. (Copy user id for next steps)
25. In admin set OpacResetPassword to Allow
26. Go back to OPAC, reload and click on “Forgot password?” link
27. Paste user id and click submit
28. Repeat steps 23 and 24
CHECK => Info message says “Your password must contain at least 12 characters, including UPPERCASE, lowercase and numbers.”
CHECK => enter an invalid password and you’ll get the same message in warning.
29. Login OPAC with the last user and your newly created password
30. Go to “Change your password” option
CHECK => Info message says “Your password must contain at least 12 characters, including UPPERCASE, lowercase and numbers.”
CHECK => enter an invalid password and you’ll get the same message in below “New password” input.
31. prove t/db_dependent/AuthUtils.t t/db_dependent/Koha/Patron/Category.t
32. Sign off
Sponsored-by: Northeast Kansas Library - NEKLS
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Sponsored-by: Northeast Kansas Library - NEKLS
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Sponsored-by: Northeast Kansas Library - NEKLS
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In get_elasticsearch_params we set the conf to static if undefined,
but we never defined it
To test:
1 - Apply unit test patch
2 - prove -v t/Koha/SearchEngine/Elasticsearch.t
3 - It fails
4 - Apply this patch
5 - It succeeds
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the controller not expect that there will always be all
the email fields. So it now checks if an email field was passed, and
changed, and renders the error if that stands.
To test:
1. Run:
$ kshell
k$ prove t/db_dependent/api/v1/patrons.t
=> FAIL: Tests written by Nick highlight a problem
2. Apply this patch
3. Repeat 1
=> SUCCESS: Problems solved
4. 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>
The API was only catching the primary email change case, but we need to
catch email, emailpro and B_email.
We were also not accounting for any of the emails (on PUT or from the
DB) being undefined.
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: 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: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
Sponsored-by: Cooperative Information Network (CIN)
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
JD Amended patch: fix md5sum
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1. Introduce a typo in swagger.json or another spec json file.
2. Restart plack if used or try to access the REST APIs
3. Without the patch, verify that an incomplete error message and potentially lots of stack trace are logged.
4. With the patch, verify that much more meaningful error messages are logged and stack trace is omitted.
5. Fix the problem introduced in step 1 and verify that no messages are logged, or only warning about bundle is logged with Debian Stretch.
6. Repeat with a REST API plugin.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are guessing authtype code and inserting the heading built accorindg to C4::Heading
If we can't identify the auth type, we can format the heading. There is a record in the koha test
data that is missing the heading field so type cannot be idenfitied
This prevents us from dying n a record where we cannot identify the type.
Note: This code will also be triggered for custom authority types, higlighting
that they won't link because of hardcoded mappings in C4::Heading. We must tackle this
on a new bug
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The match-heading field is a special field used only by the linker, not accessible
to staff or patrons via the interface. This field is used to store the constructed
'search form' used for matching bib headings to authority fields.
In bug 24269 I attempted to use the mappings defined in the inferface and also inject the search term.
This did not work as too many subfields were indexed on their own and leading to false matches.
In this bug we remove the mappings for this field, and create it ourselves during
the indexing process. The C4::Headings module is still used to generate the correct form,
however, the mappings are set based on the authority types in the system. This gives the user
the ability to add new typoes, but prevents mapping changes from breaking linker functionality
To test:
1 - Start form a sample database with ElasticSearch working
2 - Download via Z39.50 2 authorities, one of which is a narrower heading of the other, e.g.:
Waterworks
Waterworks - Costs
3 - Place a heading for the broader term in a record. e.g. Waterworks
In 650$a, without the cataloguing authority plugin. We don't want
the link created now.
You need syspref BiblioAddsAuthorities => allow
4 - Make sure linker is set to default
5 - Attempt to link the records
misc/link_bibs_to_authorities.pl
6 - Linking fails
7 - Apply patch
8 - refresh index settings (if using a custom file, remove 'match-heading')
You can reset mappings in the UI or run this:
misc/search_tools/rebuild_elasticsearch.pl -v -d -r
9 - Reindex ES
10 - Try to link again
11 - It succeeds!
12 - Run the tests
prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 25273: (follow-up)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This takes care of more occurences of staff client and changes it to
staff interface, including in code comments.
To test:
- I think in this case careful code review is what we look for.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch implements necesary code to implement non priority feature
To test:
1) Apply all patches.
2) Run updatedatabase.
3) Checkout a specific item for patron1.
4) Place a hold on the same item for patron2 (do not check non priority
hold checkbox).
5) Try to renew the item for patron1.
CHECK => in checkouts table, there is a message that the item could not
be renewed because there was a hold.
6) Cleanup all checkouts and holds.
7) repeat steps 3 to 5, but this time check the non priority checkbox.
SUCCESS => item was renewed
8) prove t/db_dependent/Holds.t
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
rel_file returns the path anyway
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
By default, JSON::Validator::OpenAPI tries to fetch the
swagger v2 schema from http://swagger.io/v2/schema.json.
If you've installed from CPAN, JSON::Validator::OpenAPI will
come with a cached copy, so it won't try to fetch it over HTTP.
However, if you've installed from libjson-validator-perl
from Debian/Ubuntu, the Debian package excludes the cached copy,
so JSON::Validator::OpenAPI tries to fetch it over HTTP.
Unfortunately, today and other days in the past, the file at
http://swagger.io/v2/schema.json has been unavailable, and this causes
Koha to crash in a perpetual loop.
This patch includes a copy of the swagger v2 schema, and it loads
it locally rather than fetching over HTTP.
The changes to Koha/REST/Plugin/PluginRoutes.pm are not required,
since the validator isn't currently called there, but I've added
a patch to future proof it.
To Test:
0a) Remove /usr/share/perl5/JSON/Validator/cache/36d1bd12eeed51e86c8695bd8876a9df
if it exists
0b) Block external access to http://swagger.io/v2/schema.json or
test during an outage when it's unavailable
0c) Do not apply patch
1) koha-plack --restart kohadev
2) Note that it crashes in a loop and is unavailable in web browser
3) Apply patch
4) koha-plack --restart kohadev
5) Note that Koha comes up and there are no errors in the Plack logs
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries would like to be able to cancel a hold with the option to
specify a reason. Providing a reason would generate an email to that
patron.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Restart all the things!
4) Create new AV category "HOLD_CANCELLATION", add some cancelation reasons
5) Add new Holds module notice "HOLD_CANCELLATION", add an email version.
A quick test version would be "Reason: <<reserves.cancellation_reason>>"
--
[% USE AuthorisedValues %]
Reason: [% AuthorisedValues.GetByCode( 'CANCELLATION_REASON', hold.cancellation_reason, 'IS_OPAC' ) %]
[% IF hold.cancellation_reason == "MY_AV_VALUE" %]
IF perhaps you'd like to have a much longer explanation than just the
one sentence in the AV description, you can use IF blocks using Template
Toolkit markup!
[% END %]
--
6) Place a hold for a patron
7) On request.pl, select the 'del' option for the hold
8) Select a cancellation reason and choose "Update hold(s)"
9) Note a new message has been queue for the patron with the cancelation reason
11) Test again from circulation.pl
12) Test again from moremember.pl
10) Cancel a hold with no reason, note no email is generated
11) Delete your authorised values, not the feature is disabled
12) Reinstate the authorised values, but delete the notice,
you should now be able to cancel a hold with a reason,
but no email will be generated
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Rebecca Coert <rcoert@arlingtonva.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes the behaviour for the POST /holds route. It assumed
maxreserves was checked in CanItemBeReserved which is not the case.
Tests are added to check for this behaviour.
To test:
1. Apply the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/holds.t
=> FAIL: Tests 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: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It prevents valid_template check to raise
Can't call method "filter_by_current" without a package or object reference at /kohadevbox/koha/Koha/Template/Plugin/Context.pm line 49.
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "norequest" boolean passed to the include cat-toolbar.inc, to
display or not the "Pace hold" button.
This flag was not calculated in some place (ISBDdetail and moredetail
for instance)
Here we centralize the code to make it more robust and less regression
prone.
Note that the same problem appears at the OPAC (opac-MARCdetail is
always display the button). That will have to be fixed separately
Test plan:
Create biblio A with 0 item, B and C with 1 item and D with 2 items
item for B is not for loan, C is for loan and D has 1 of each
Go to the bibliographic detail page of each record and confirm that the
"Place hold" button appears appropriately.
Test the different tabs of the catalogue module
QA note: This patch is only centralizing the existing code, but it is
still too naive. To manage the visibility of this button we certainly
want to copy what is done in C4::Search::searchResults:
# can place a hold on a item if
# not lost nor withdrawn
# not damaged unless AllowHoldsOnDamagedItems is true
# item is either for loan or on order (notforloan < 0)
$can_place_holds = 1
if (
!$item->{itemlost}
&& !$item->{withdrawn}
&& ( !$item->{damaged} || C4::Context->preference('AllowHoldsOnDamagedItems') )
&& ( !$item->{notforloan} || $item->{notforloan} < 0 )
);
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Tomas Cohen Arazi
Marcel de Rooy
Nick Clemens
Fridolin Somers
Colin Campbell
Jonathan Druart
David Gustafsson
David Gustafsson
Agustin Moyano
Kyle M Hall
Martin Renvoize
Ere Maijala
Katrin Fischer
David Cook