This column was not used in the Koha codebase, it can be removed.
Test plan:
Execute the updatedatabase.pl script and confirm that the column has
been dropped.
QA step:
1/ git grep totalamount
2/ prove t/db_dependent/Acquisition.t
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch test 'IsOverDriveEnabled' subroutine
TEST PLAN
---------
1. Apply patch
2. prove -v t/External/OverDrive.t
-- All tests should run successfully without
any error or warning
TEST PLAN OPTIONAL
------------------
Check with bug 13899 to see the coverage of this module.
Coverage BEFORE this patch :
Statement : 47,5%
Branch : 0,0%
Condition : 0,0%
Subroutine : 75,0%
Coverage AFTER this patch :
Statement : 49,1%
Branch : 0,0%
Condition : 33,3%
Subroutine : 83,3%
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Tests tun, no koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
1. Replace all calls to $sth->fetchrow_array
with a call to $dbh->selectrow_array
2. Cleaning Review.t file with perltiny
3. Cleaning Review.t && Review.pl files with koha-qa tool
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Testing C4::Review in t/db_dependent/Review.t
Adding a pod for every sub
TEST PLAN
---------
1. Apply patch
2. prove -v t/db_dependent/Review.t
-- All 117 tests should run successfully without
any error or warning
TEST PLAN OPTIONAL
------------------
Go check bug 13899 and see that coverage is 100% for this module.
Coverage BEFORE this patch :
Statement : 21,9%
Branch : 0,0%
Condition : 0,0%
Subroutine : 33,3%
Pod : 33,3%
Coverage AFTER this patch :
Statement : 100,0%
Branch : 100,0%
Condition : N/A
Subroutine : 100,0%
Pod : 100,0%
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
All tests run
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The tile displayed only with steps #1 and #2
This patch adds the title to the following steps.
To test:
Home > Reports
Click on 'Build new'
Step through steps 1 - 6
Verify that title displays with each step.
Sponsored-by: Universidad de El Salvador
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To verify and test:
Go to Home > Reports
Click on 'Build new'
Verify that the title in Step 1 and to display with correct capitalization
Sponsored-by: Universidad de El Salvador
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The preference was missing a 'd' in the word address.
To test:
* Visit preferences
* Visit I18N/L10N tab
* Confirm spelling of options in Addressformat preference
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Spelling is right, no errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The script that returns data for the patron autocomplete does not use C4::Members::Search. Instead it uses bespoke code that does not behave like the traditional search and is very limited in how it can search.
If, for example, I search for "Kyle Hall" in the standard search, I would get "Kyle Hall" back as a result. For the autocomplete search, I will not.
This script should use C4::Members::Search to provide better searching and to keep the code base DRY.
Test Plan:
1) Enable the system preference CircAutocompl
2) Create a user with the first name "Test" and the surname "User"
3) Perform a checkout autocomplete search for "Test User"
4) Note you do not get the user as a result
5) Apply this patch
6) Try different combinations of "Test" and "User" such as
Test User
User Test
U Test
Test U
etc.
7) Note these searches now work
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Currently batch_id is assigned upon creation of a new batch object. This patch leaves batch_id as 0 at creation and adds a check when adding items. If batch is new then batch_id is created then
Test plan:
1 -In one browser window, go to tools->label creator and click the new batch button
2 - Before adding items, open a new browser, and go tools->label creator and click the new batch button
3 - Note that both batches have the same number listed
4 - Add an item to the first batch - you should now see one item in the batch
5 - Add an item to the second batch, you should see two items in the batch
6 - Apply patch and repeat steps 1&2
7 - Note that neither batch lists a batch number
8 - Add an item to the first batch, you should see one item and a batch number
9 - Add an item to the second batch, you should see one item and a new batch number
Patch behaves as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
At the moment, it is possible to create records in acquisitions, but the
ACQ framework is only used for items created in this module.
This patch allows to defined default values in the ACQ framework for
records created on the acquisition module.
Test plan:
1/ Make sure you have the ACQ framework created (otherwise create it
from the default framework).
2/ Define a default value for a field (for instance 099$z=1).
3/ Go in the acquisition module and create a new order from a new
record.
4/ Fill mandatory information and save.
5/ Go on the detail page of this record and verify the default value
exist.
Signed-off-by: Gaetan Boisson <gaetan.boisson@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Correct $KOHA::VERSION to $Koha::VERSION.
Also, passing this string to LWP::UserAgent is wrong. It expects key/value
pairs. Since this string is apparently intended as an agent, this patch
passes it as such.
Note: The OverDrive has unfortunately no unit tests.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested this change in the perl debugger with just these lines:
use C4::External::OverDrive;
C4::External::OverDrive::_request();
Printed $ua->agent while stepping into sub _request.
Without the agent change, the adjusted Koha string would just be ignored
and I would still have "libwww-perl/6.04" as agent.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
As per Chris' comment #17, this improves the testing coverage.
Same test plan as comment #16, but add:
TEST PLAN SUPPLEMENT
--------------------
1) $ prove -v t/db_dependent/Borrower_Discharge.t
-- notice only 5 tests, and generate_as_pdf not tested.
2) Apply this patch.
3) Retest as per comment #16
-- this will test the error and no error cases
tweaked in Koha/Borrower/Discharge.pm
4) remove PDF::HTML
$ sudo apt-get purge libpdf-fromhtml-perl
5) $ prove -v t/db_dependent/Borrower_Discharge.t
-- 7 tests, all successful
6) add PDF::HTML
$ sudo dpkg -i /path/to/libpdf-fromhtml-perl...
-- depends on how you get it. vary accordingly.
7) $ prove -v t/db_dependent/Borrower_Discharge.t
-- 7 tests, all successful
-- Note that is was a different 7th test. :)
8) koha qa test tools
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since this is only in generate_as_pdf of Koha::Borrowers::Discharge, it made
sense to change it from a use to a require (avoiding a compile time error),
and placing it inside the eval where the PDF is generated, thus capturing the
problem in the koha error log.
TEST PLAN
---------
1) Log in to staff client
2) Koha Administration -> Global system preferences -> Local Use
3) Lower the Version number by 1, but DO NOT CLICK SAVE.
4) At the command line, sudo apt-get purge libpdf-fromhtml-perl
5) Back in the staff client, click save.
6) Every looks great until you attempt to log in. KABOOM!
7) Apply patch
8) Log in to staff client
-- YAY!
9) Koha Administration -> Global system preferences -> Patrons
10) Make use the useDischarge is set to Allow
11) Find a patron with nothing checked out.
12) There is now a Discharge tab on the left at the bottom.
13) Click the 'Generate Discharge' button.
-- nice error message
-- check koha error log file for the ugly @INC missing message
14) At the command line, reinstall PDF::FromHTML
(I built my own with cpan2deb: sudo dpkg -i /path/to/libpdf-fromhtml-perl_...)
15) In the staff client, click the 'Generate Discharge' button again.
-- PDF is created as expected. All is well.
16) run koha qa test tools.
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It will permit not to run another perl interpreter.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch removes the home made pagination and introduces datatables on
this page.
Test plan:
Go to the authority type admin page and confirm there is a beautiful
table.
Confirmed...
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The reports dictionary allows the user to select several fields, but
only 1 is used.
The interface is quite confusing.
This patch removes the multiple selection and permit to select only 1
field.
Test plan:
1/ Create a report dictionary (reports/dictionary.pl)
2/ On the step 3, confirm that only 1 field can be selected
Confirm there is no regression on this tool.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Sometime you get the "Nothing to save" message when clicking on the "save
all preferences" button, even if something has changed.
On irritating behavior is the middle click: if you use the middle click
to paste some text in the input, the "keyup" event won't be trigger.
This patch replaces the "keyup" event with the "change", which works
as we want here.
The issues:
1/ Search for "wanted" (admin/preferences.pl?op=search&searchfield=wanted)
Empty the input, click save
Type something and remove it
You are able to save, but nothing has changed
2/ Put something in your selection buffer and use the middle click to
paste it in the input.
No change detected.
Test plan:
Confirm the issues are fixed and you don't find any regression
Note that now the "(modified)" string is displayed when the input loses
the focus.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It seems that the previous patch does not stop the propagation of the
event if the link is clicked with the left button (which=1).
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The browse results feature (bug 10404) modified the click events on
titles on the search result page (intranet).
It introduced bad behaviors:
1/ ctrl+click on a title does not open a new tab
2/ middle click on a title does open a new tab but the browser is not
displayed.
Note that this patch is not perfect, it fixes the 2 bad behaviors but
the ctrl+click gives the focus to the new tab (could go against the
preferences of the users).
Test plan:
1/ On the staff interface, launch a search (catalogue/search.pl?q=XXX)
2/ When middle-clicking on a title, a new tab should open. On this tab
the browse result feature should be displayed
3/ Same for cltr+click
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the staff search results, if an item is both checked out and lost,
the result will appear as two item lines where one line has the lost
status and the other line has the rest of the item's data.
Test Plan:
1) Check an item out to a patron
2) Mark the item as lost *without* removing the item from the patron's
record, either by using longoverdue.pl or by editing the itemlost
field in the database directly.
3) Perform a search where that item will be in the results
4) Note the improper display of the item's data
5) Apply this patch set
6) Reload the search restults
7) Note the item now displays correctly
Signed-off-by: Nick <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Nick <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Page uses TAGS Directive in order to print TT directives
in the manual without having them interpreted, but fails
to switch back/change all following TT code, causing
problems in displaying the file correctly.
See TT documentation:
http://www.template-toolkit.org/docs/manual/Directives.html#section_TAGS
As [- ... -] showed up in translations, I chose to switch back
instead of changing the TT variable and INCLUDE.
To test:
- Go to tools > csv profiles
- Open the help page
- Verify the link to the manual includes the version and works
- Verify the footer shows up correctly with the edit buttons
Works as expected.
Signed-off-by: Marc Veron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The phrase
Please type this following characters into the preceding box
should be
Please type the following characters into the preceding box
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes some minor display issues in 'Add order from a suggestion'
To test:
- Add order form a suggestion
- The copyright date iss dispayed like 'copy.year:2015'
- Apply patch
- The copyright date now displays as (copyright sign) 2014, similar to the display in suggestion management
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This match sets $sortby (previously undefined value) as an empty string to get rid of the warns.
To test:
1) Go to a URL such as http://localhost:8080/cgi-bin/koha/opac-authorities-home.pl?op=do_search&type=opac&operator=contains&value=a&marclist=any&and_or=and
2) Notice the warns in the error log
3) Apply patch
4) Reload URL
5) Notice page still works but no warns in error log
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: I would have done $sortby //= '';
But this works too. :)
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The trick to update the suggestions table width is outdated since jQuery
UI has been updated.
Test plan:
0/ Don't apply this patch
1/ Go on the suggestions page (suggestion/suggestion.pl), change tabs:
the table width is wrong
2/ Apply this patch
4/ Repeat 1 and confirm the width is now updated.
Signed-off-by: Christopher Brannon <cbrannon@cdalibary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
The table sizes still vary slightly, but this is an improvement.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When creating a new report, the limit step let you choose
itype|itemtype.
But it should be itype|itemtypes.
If you try to create a guided report and you choose this option as a
limit, you will get a warning on saving it:
Errors found when processing parameters for report:
itype: The authorized value category (itemtype) you selected does not exist.
Looking at the code: reports/guided_reports.pl l.657
elsif ( $authorised_value eq "itemtypes" ) {
Test plan:
0/ Don't apply the patch
1/ Create a guided report, select Koha itemtype as a limit(step 4)
2/ Confirm you get the error when saving
3/ Apply the patch and repeat step 1
4/ There is no error and the report should work correctly
Tested with steps in comment #4/#5, error is gone after applying patch.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The file templates.readme dates back to CSV and
HTML::Template times and is outdated.
To test:
- Verify the file is outdated and removed by this patch.
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
If noone spotted the outdatedness of this file until now I
agree with Katrin that we should get rid of it and maybe
create something similar in the wiki. The patch works as
advertised.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
At the OPAC and the intranet, the urls don't be displayed anymore.
The variables used in the templates are not the good ones (MARCurlS vs
MARCURLS).
Test plan:
1/ On the intranet side, add some urls to some records
2/ Add these records to the basket
3/ Add records without urls defined
4/ Go on the basket view, click "more details"
5/ You should see the urls displayed
6/ Repeat steps 4-5 at the OPAC
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: 856$u displays now in intranet and OPAC. :)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The "Date Due" column for checkouts is using the column index 1 to sort by.
This column is the one that is used for grouping items into today's checkouts
and previous checkouts. This is definitely not the column that should be used.
Instead, we should be using column index 2, which contains the raw unformatted
due date.
Revised Test Plan:
1) Find a patron with no checkouts
2) Check out something as due the beginning on the month.
3) Check out something as due the end of the month.
4) Check out something due tomorrow (hopefully not end of month)
-- so you should have 2015-04-01, 2015-04-30, and 2015-04-14
(for example)
5) Attempt to sort by due date
-- Note the sorting is incorrect
6) Apply this patch
7) Clear your browser cache
8) Reload the page
9) Attempt to sort by due date again
-- Note the sorting works correctly this time
10) Verify there are no regressions with bug 13908
-- this will require finding a patron with many checkouts,
playing with the Circulation system preferences
previousIssuesDefaultSortOrder and todaysIssuesDefaultSortOrder,
and understanding what the four different cases mean with
respect to actually manually sorting the 'Due Date' column.
NOTE: I did not do step 10,
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12412 introduced a way to use plugins to generate MARC records
out of any arbitrary format. But failed to properly check for
a valid configuration (plugins_enabled entry on koha-conf.xml, and
even the UseKohaPlugins syspref).
This patch makes tools/stage-marc-import.pl test for the required
configuration before attempting to create the Koha::Plugins object.
To test:
1/ Make sure you don't have a plugins_enabled entry on your koha-conf.xml file
2/ On master, browse to tools/stage-marc-import.pl
=> FAIL: You get a nasty "Can't call method "GetPlugins"..." error
3/ Apply the patch and reload
=> SUCCESS: Stage MARC for import page renders correctly
Repeat with plugins_enabled == 0 and == 1. Also UseKohaPlugins enabled/disabled.
It should work as expected.
Regards
Tomas
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works as described, no koha-qa errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
change table id in css file
+ C4::Output is used (Undefined subroutine
CGI::output_html_with_http_headers)
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
When editing an item, the call number browser search for existing call number. If it shows a line is green between two calli numbers, the call numbers searched is available. If the call number is highlighted in red, it means that it already exists. This can be used to avoid repeated call numbers in your collection.
The call number browser also shows its position relative to the rest of the collection.
Sponsored-by: CCSR
To test :
1) Go to MARC bibliographic framework
Home › Administration › MARC frameworks
2) Click in MARC structure (Default framework)
3) Search field 952 and click in subfields
4) Edit subfield o (Full call number)
5) Click Display more constraints
6) In Others Options, Plugin, Choose cn_browser.pl and save changes
7) Search a record and edit its items
Validate : three points (…) beside Full call number input
8) Click in …
Validate : if it can not find the given call number, a green line is shown. Otherwise, the given call number is highlighted in red.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Magnus <magnus@enger.priv.no>
Works as advertised. QA scripts pass.
Tested together with other patches. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Bug 13364 - fix datatables.inc
http://bugs.koha-community.org/show_bug.cgi?id=13364
Signed-off-by: Magnus <magnus@enger.priv.no>
Works as advertised. QA scripts pass.
Tested together with other patches, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Bug 13364 - Add a call number browser in item edition page - QA fixed
Tested together with other patches.
Signed-off-by: Marc Véron <veron@veron.ch>
Bug 13364 - Add a call number browser in item edition page - QA fixed II
Tested together with oter patches.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
As far as I can tell $sunday is never used. And it seemed to be
scoped to only _init.
The remaining hashiness was cleaned up for the $return_by_hour.
TEST PLAN
---------
1) Apply both patches
2) (Skip this one - file does not exist / MV) prove -v t/db_dependent/Calendar.t
3) prove -v t/db_dependent/Holidays.t
4) prove -v t/Calendar.t
5) perlcritic -3 Koha/Calendar.pm
-- the message corresponds to a comment in the code already
and not this change.
6) run koha qa test tools
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The Readonly and Readonly::XS package are only used in Koha::Calendar.
IMO the added value of there packages does not justify their purpose.
Test plan:
1/ Remove Readonly and Readonly::XS
2/ Open the calendar and confirm you don't get any error concerning missing
dependency
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch is a rough start. I believe it runs exponentially
faster, but its equality to the previous version needs to be
tested before I clean it up to acceptable standards.
Nested hashes of hashes was being a debugging nightmare.
Moved the SQL select to C4::Koha.
Changed the GetItemsForInventory to have a hashref parameter.
Added interface, in case there is a need for 'opac' vs. 'staff'.
Added t/db_dependent/Items/GetItemsForInventory.t
Added t/db_dependent/Koha/GetKohaAuthorisedValuesMapping.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
