The kohadevbox has admin/admin set, so for testing when
creating the initial superuser, if you wish to minimize
effort, use admin/admin. Otherwise, make sure to:
export KOHA_USER={whatever your user is}
export KOHA_PASS={whatever your password is}
before attempting to run the test.
Also, this test was failing because of a validation check on
the passwords requiring uppercase letters, lowercase letters,
and numbers. Changed the sample data passwords to fix.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This selenium test goes through the process of creating a category and
patron user (as is completed in the basic_workflow.t test) then the
superlibrarian used to create them is logged out and the newly created
patron user authenticates into the OPAC and staff intranet therefore testing the
authenitcation of both.
Test plan (this test plan includes how to install Selenium as well as
how to run this test, for the benefit of people who have not got
Selenium installed on their machines):
1. wget https://selenium-release.storage.googleapis.com/2.53/selenium-server-standalone-2.53.0.jar
2. vim /etc/apt/sources.list.d/firefox.list
3. Paste into the file:
deb http://packages.linuxmint.com debian import
4. sudo apt-get update
5. sudo apt-get install firefox
6. sudo apt-get install xvfb
7. Set the SELENIUM_PATH vartiable:
SELENIUM_PATH=/home/vagrant/kohaclone/selenium-server-standalone-2.53.0.jar
8. Xvfb :1 -screen 0 1024x768x24 2>&1 >/dev/null &
9. DISPLAY=:1 java -jar $SELENIUM_PATH
Note: This will start up the selenium server. Everytime you want to shut
down this terminal window and want to restart Selenium just run the step
9 command to restart the Selenium server
10. Open a new terminal window and write in:
git clone https://github.com/gempesaw/Selenium-Remote-Driver --branch
build/master --single-branch --depth 1
11. cd Selenium-Remote-Driver
12. perl Makefile.PL
13. make
14. make test
15. sudo make install
16. Now everything is installed and you can et up for running the selenium tests
17. Create a superlibrarian user with the username koha and password
koha
18. If your usual port configuration for the intranet and OPAC is 8081
and 8080 respectively then set the staffClientBaseURL and OPACBaseURL
system preferences to localhost:8080 and localhost:80 respectively
19. sudo koha-shell <instancename>
20. perl t/db_dependent/selenium/authenticate.t
21. The test should pass.
Note: The time_diff comments in the test output showing what the test is
doing
Note: If you have issues with installing Selenium and
Selenium::Remote::Driver please write a comment on the bug report and I
will be more than happy to create a screencapture video showing all the
steps
Sponsored-By: Catalyst IT
https://bugs.koha-community.org/show_bug.cgi?id=19181
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
Run t/db_dependent/Virtualshelves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
While we get packaging sorted, Net::OAuth2::AuthorizationServer is not a
hard dependency for Koha and the feature requiring it is disabled by
default.
This patch:
- Makes the dependency optional
- Makes the unit tests for the OAuth2 client credentials flow skip if
the dependency is not met.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch tests the situation in which Net::OAuth2::AuthorizationServer
is missing. It mocks Module::Load::Conditional::can_load and expects the
/token endpoint answers 'Unimplemented grant type' to all requests, and
the 'authenticate_api_request' in 'under' exit with unauthorized (403)
to requests in which the Authorization header is passed containing a
Bearer token, but OAuth2 is not really available.
To test:
- Apply this patch
- Run:
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> FAIL: Tests fail because our REST endpoints don't support this
behaviour.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds tests to verify that disabling the RESTOAuth2ClientCredentials syspref
makes any request on the /api/v1/oauth/token using the
'client_credentials' grant fail with 'grant not implemented'.
To test:
- Apply this patch
- Run:
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> FAIL: Tests fail because the change is not implemented!
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the oauth.t tests leverage on the new Koha::ApiKey(s)
classes. It adds tests for expired tokens too.
To test:
- Apply this patch
- Run:
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> FAIL: Tests should fail without the rest of the patches.
Sponsored-by: ByWater Solutions
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Benjamin Rokseth <benjamin.rokseth@deichman.no>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds unit tests for the introduced classes: Koha::ApiKey(s).
To test:
- Apply this patch
- Run
$ kshell
k$ prove t/db_dependent/Koha/ApiKeys.t
=> FAIL: Tests fail because the feature is not implemented.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GET /patrons now requires { "borrowers": 1 } instead of
{ "borrowers": "edit_borrowers" }
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It implements only the "client credentials" flow with no scopes
support. API clients are tied to an existing patron and have the same
permissions as the patron they are tied to.
API Clients are defined in $KOHA_CONF.
Test plan:
0. Install Net::OAuth2::AuthorizationServer 0.16
1. In $KOHA_CONF, add an <api_client> element under <config>:
<api_client>
<client_id>$CLIENT_ID</client_id>
<client_secret>$CLIENT_SECRET</client_secret>
<patron_id>X</patron_id> <!-- X is an existing borrowernumber -->
</api_client>
2. Apply patch, run updatedatabase.pl and reload starman
3. Install Firefox extension RESTer [1]
4. In RESTer, go to "Authorization" tab and create a new OAuth2
configuration:
- OAuth flow: Client credentials
- Access Token Request Method: POST
- Access Token Request Endpoint: http://$KOHA_URL/api/v1/oauth/token
- Access Token Request Client Authentication: Credentials in request
body
- Client ID: $CLIENT_ID
- Client Secret: $CLIENT_SECRET
5. Click on the newly created configuration to generate a new token
(which will be valid only for an hour)
6. In RESTer, set HTTP method to GET and url to
http://$KOHA_URL/api/v1/patrons then click on SEND
If patron X has permission 'borrowers', it should return 200 OK
with the list of patrons
Otherwise it should return 403 with the list of required permissions
(Please test both cases)
7. Wait an hour (or run the following SQL query:
UPDATE oauth_access_tokens SET expires = 0) and repeat step 6.
You should have a 403 Forbidden status, and the token must have been
removed from the database.
8. Create a bunch of tokens using RESTer, make some of them expires
using the previous SQL query, and run the following command:
misc/cronjobs/cleanup_database.pl --oauth-tokens
Verify that expired tokens were removed, and that the others are
still there
9. prove t/db_dependent/api/v1/oauth.t
[1] https://addons.mozilla.org/en-US/firefox/addon/rester/
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If items.restricted == 1, CanBookBeIssued will not returned what we are
testing.
The easiest and global fix is to define a default value at TestBuilder
package level
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
0) Apply this patch
1) prove t/db_dependent/Members/Attributes.t
should return green
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN
---------
apply this test patch
prove t/db_dependent/OAI/Server.t
-- should fail
apply the other patch
prove t/db_dependent/OAI/Server.t
-- should pass
run koha qa test tools
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Sponsored-by: Goethe-Institut
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
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>
The same pattern is used several times in test:
checkout, checkin, get the debarment, compare the dates and remove the
debarment.
Let's move that to a separate subroutine
Sponsored-by: Goethe-Institut
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
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 patchs adds the ability to calculate the end of the suspension date
(debarment date) using the finesCalendar syspref.
Prior to this patch it was never calculating without taking into account
the calendar.
calculated without taking holidays into account.
This was a problem because the restriction could end in the middle of a
period the library is closed.
Test plan:
- Set finescalendar to 'not including days the library is closed'
- Set a circulation condition with no fine/maxfine, but fine days and
max fine days instead
- Check out an item with a due date in the past
- Check the item in and verify the restriction date
- Clean the restriction
- Add holidays to your calendar on the calculated restriction date
- Check the item out again with the same due date in the past
- Check in the item again
- Verify the calculated restriction end date has changed, it's set to the day
after the holiday.
Fines in days restriction calculation is correctly taking calendar
into account.
Sponsored-by: Goethe-Institut
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
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>
Test Plan:
1) Apply this patch and its' dependencies
2) Create and pay some various fees and fines
3) View the payments for fees, and fees paid by payments by
using the new 'Details' button available on boraccount.pl
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
Running updatedatabase.pl after patch application makes dependencies
happy. Passes QA Tools and works as intended.
Rebased (2017-12-21): Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 2696: (QA follow-up) - Remove use of GetMember
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch removes 3 subroutines from C4::Letters:
- getalert
- addalert
- delalert
And add 3 methods to Koha::Subscription:
- subscribers
- add_subscriber
- remove_subscriber
It makes the code cleaner for future cleanup.
TODO - we should remove alert.alertid and alert.type, and rename
alert.externalid with alert.subscriptionid
That way alert will be renamed borrowers_subscriptions (or similar) and
will become a simple join table between borrowers and subscriptions.
We will need to deal with FK that could not be satisfied.
Let's do that after this patch is pushed.
Test plan:
Subscribe and unsubscribe to email notifications sent when a new issues
is available.
Make sure everything works as before and you receive the emails.
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 looks like this feature has never been finished. It has been
developed with more flexibility in mind, but only 'issue' is used for
this parameter. Apparently it could have been 'virtual', for virtual shelves.
Let remove this parameter and clean the code a bit.
TODO: Remove the DB column
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>
- "your routing lists" tab is now highlighted when active
- get_routinglists was renamed to get_routing_lists
- Koha::Patron->get_routing_lists returns the ->search result
directly
- Koha::Subscription::RoutingList->subscription uses DBIC
relationship
- Undo changes to C4/Auth.pm
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the base for the new feature:
Show a list of the serial titles a patron is on routing
lists for in the OPAC.
Test plan applies to the complete patch set:
To test:
- Apply all patches
- Make sure RoutingSerials is not activated
- Check patron account in OPAC - no tab should appear
- Activate RoutingSerials
- Create subscriptions and different routing lists, test with:
- Patron with no routing list entries = no tab
- Patron with one or more routing list entries = tab appears
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20400: Rewrite using Koha::Objects
Adds
- Koha::Subscription::Routinglist
- Koha::Subscription::Routinglists
Adds 2 methods
- Koha::Patron::get_routinglists
- Koha::Routinglist::subscription
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20400: Add unit tests
prove t/db_dependent/Koha/Subscription/Routinglists.t
prove t/db_dependent/Koha/Patrons.t
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20400: Display new tab in OPAC only for patrons with routing lists
The visibility of the routing list tab in the OPAC depends
on the system preference RoutingSerials and the existence
of routing list entries for the patron.
Some libraries only offer routing lists to certain user groups and
would not want it generally visible. As there are currently no
actions you can perform from the list, this appears to be a
reasonable behaviour.
See test plan in first patch.
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20400: (follow-up) Use Asset TT plugin on opac-routing-lists.tt
Patch applies and functions as described.
Signed-off-by: Dilan Johnpullé <dilan@calyx.net.au>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Bug 20400: (QA follow-up) Redirect to 404 if routing is disabled
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves the Koha::Patrons->merge method into
Koha::Patron->merge_with in the line of the discussed implementation for
bug 15336. I agree with that implementation so I provide this follow-up.
Tests are adjusted, the controller script is adapted too. The behaviour
remains.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It would be great if there were a merge patrons feature. If you
accidentally end up with one patron with two cards it would be nice to
merge their records together so that you don't lose their history or
holds or anything.
This patch adds a basic patron merge feature. It attempts to relink all
patron related tables from the patron(s) to be merged. It does not
attempt to relink librarian account related tables at this time. This
feature does not attempt to automatically resolve issues such as
duplicate holds. Such a feature could build upon this one though.
Test Plan:
1) Apply this patch
2) Find two or more patrons
3) Perform a patron search that will bring them up on the same page of
results, or add them all to a list of patrons.
4) Use the 'merge' button to begin the merging process
5) Choose a patron to keep
6) Verify the deleted patrons data ( checkouts, holds, etc )
are now linked to the kept patron
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Ed Veal <eveal@mckinneytexas.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - prove t/db_dependent/Koha/Z3950Servers.t
2 - Load cataloging and authority home pages
3 - Verify you can add form z395 on each page
4 - Delete all z3950 servers
5 - Viery option to add from Z3950 is removed on both pages
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
0) Do not apply the patch
1) Run these 3 commands
git grep ModNote
git grep getcredits
git grep getrefunds
all should return occurances only in C4/Accounts.pm - the sub definition
and in t/db_dependent/Accounts.t
2) Apply the patch
3) Run commands from 1) again, now there should be no occurence
4) prove t/db_dependent/Accounts.t
should return green
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
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: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Given the confusion regarding this behaviour it sounds better to make it
configurable.
This pref will take 4 different values, 1 per place an item can be
marked as lost.
Test plan:
Mark items as lost and confirm the item is returned or not, depending on
the value of the system preference.
- from the longoverdue cronjob (--mark-returned takes precedence if set)
- from the batch item modification tool
- when cataloguing an item
- from the items tab of the catalog module
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We've had the ability to 'reverse' a payment for a long time, but it
would be much better if we had a true void payment function that
replaces the paid amounts into the fee so that it appears as if the
payment was never made.
Test Plan:
1) Apply this patch and dependent patches
2) Run updatedatabase.pl
3) Create some fines
4) Pay those fines
5) Use the new 'void' button to void the payments
6) Note the fines were restored to their pre-payment amounts
Signed-off-by: Koha-us conference <koha-us@koha-us.net>
Signed-off-by: BWS Sandboxes <ByWaterSandboxes@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some libraries would like to be able to specify more specific payment types such as cash, check, credit card, or even canned food ( for food drives ). This feature will allow a library to specify payment types as authorised values of the type PAYMENT_TYPE.
Test Plan:
1) Apply patches
2) Update database
3) Add authorised value PAYMENT_TYPE with values 'Cash', 'Check', 'Credit card'
4) Go to the fines section of a patron who has several fines
5) Tab 'Fines'
6) Click on 'Pay' for an individual fine
7) Verify that in the form a 'Pay an individual fine' dropdown appears with payment types
8) Select a payment type, confirm payment
9) Verify that payment type appears in "Description of charges" in tab 'Account'
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Bug 18786: Remove use of Koha::Patron::Images
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Bug 18786: Remove duplicate block with bad IF
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
prove t/db_dependent/Koha/Subscription.t
must return green
NOTE: My preference is for $subscription to be object,
and perhaps something like $built_subscription to
be from the builder. Because, $object is a poor
variable name.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do not need to pass all those parameters, just the checkout object is
enough.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Apply this patch
2) Assign a charge to an item type
3) Checkout an item of that type to a patron
4) View the accountlines table for that patron
SELECT * FROM accountlines WHERE accounttype='Rent' and borrowernumber=##;
5) Note there is an issue_id
Or
1) Apply this patch
2) prove t/db_dependent/Circulation/issue.t
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Moving the status to the invalid 'processing' might well have unwanted
side-effects. (The status column will be set to empty string and we have
a problem if it is not processed.)
This patch allows pass-through of DBIX's make_column_dirty in
Koha::Object (simple tests included) and uses it to force an update.
If the update does not return true, it still exits.
Test plan:
[1] Read the changes.
[2] Run t/db_dependent/Koha/Object.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Having to write [% KOHA_VERSION %] for each url is bad because:
- It's easily forgettable when adding new <script> or <link>
- It prevents grep'ing for the full filename
- It violates the DRY principle
- If at some point we want to change the "force js and css reload"
mechanism, it will be tedious
This patch:
- adds a Template::Toolkit plugin that generates <script> and
<link> tags for JS and CSS files, and inserts automatically the Koha
version in the filename
- use the new plugin to remove all occurences of [% KOHA_VERSION %]
- remove the code that was adding KOHA_VERSION as a template variable
Test plan:
1. Apply patch
2. Go to several different pages in Koha (opac and intranet) while
checking your browser's dev tools (there should be no 404 for JS and
CSS files, and the Koha version should appear in filenames) and the
server logs (there should be no "File not found")
3. `git grep KOHA_VERSION` should return nothing
4. prove t/db_dependent/Koha/Template/Plugin/Asset.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN
---------
1) apply this patch
2) prove t/db_dependent/Circulation.t
-- horrible death.
3) apply next path
4) prove t/db_dependent/Circulation.t
-- passes.
5) run koha qa test tools
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>