On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Inventory explodes with the following stacktrace if timeformat is set to 12h
Invalid value passed, datelastseen=2021-04-09 12:00 AM expected type is date at /usr/share/perl5/Exception/Class/Base.pm line 88
Exception::Class::Base::throw('Koha::Exceptions::Object::BadValue', 'type', 'date', 'value', '2021-04-09 12:00 AM', 'property', 'datelastseen') called at /kohadevbox/koha/Koha/Object.pm line 196
Koha::Object::catch {...} ('DBIx::Class::Exception=HASH(0x557a052baeb0)') called at /usr/share/perl5/Try/Tiny.pm line 124
Try::Tiny::try('CODE(0x557a051931d8)', 'Try::Tiny::Catch=REF(0x557a052bfc30)') called at /kohadevbox/koha/Koha/Object.pm line 206
Koha::Object::store('Koha::Item=HASH(0x557a0521a048)') called at /kohadevbox/koha/Koha/Item.pm line 202
Koha::Item::store('Koha::Item=HASH(0x557a0521a048)') called at /kohadevbox/koha/tools/inventory.pl line 220
Test plan:
Set TimeFormat to 12h
Use the inventory
=> Confirm that it's working with this patch applied
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the ability to filter inventory by item type. Multiple
item types can be selected at once.
To test:
1) Apply patch and restart services.
2) Set up (at least) one item of a specific item type.
3) Go to Tools -> Inventory.
4) Scroll down to find the item types filter. Confirm the 'select all'
and 'clear all' buttons work as expected.
5) Select a few item types, but DO NOT include the item type that you
just set for your item. Confirm that your item does not show in the
results.
6) Go back to the Inventory tool. This time submit a search that DOES
include the item type you just set for your item. Confirm that your item
does show in the results.
7) Confirm tests pass:
prove t/db_dependent/Items/GetItemsForInventory.t
Sponsored-by: Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan :
- Check you have in default framework an item subfield mapped with items.notforloan and with an authorized value catergory,
for example 'NOTFORLOAN'
- Create a new value in this category, for example '9'
- Create a biblio with default framework
- Create an item with barcode='000AAA1', callnumber='A-1' and notforloan=0
- Create an item with barcode='000AAA2', callnumber='A-2' and notforloan=9
- Create a file 'barecodes.txt' containing 2 lines '000AAA1' and '000AAA2'
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Choose file in 'Barcode file'
- Enter item callnumber between 'A-0' and 'A-9'
- Check 'Compare barcodes list to results'
- Submit=> without patch, you get no warnings
- Redo the same inventory but with checking items.notforloan 'For loan'
(using the browser back page is ok)
- submit => still no warning, Bug 000AAA2 must be listed it's not 'For loan'
- Apply patch, repeat, with tems.notforloan 'For loan' checked you get the
right warning
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch allows the user to scan barcodes in the inventory tool
(in addition to upload a barcode file, like in other tools)
Test plan:
1) Apply the patch.
2) Check that you can still upload a barcode file.
3) Check that you can scan/enter barcodes in the new textarea.
4) Check that if you both upload a barcode file and enter barcodes,
you will be prompted to choose only one method.
5) Check that you can then proceed to the next step by either resetting the
upload file input or emptying the textarea.
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>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Follow-up work
commit bbb504c86f
Bug 23463: Replace ModItem with Koha::Item->store
Test plan :
- Create a biblio with default framework
- Create an item with barcode='000AAA1', callnumber='ZZZAAA1'
- Create an item with barcode='000AAA2', callnumber='ZZZAAA2'
- Create a file 'barecodes.txt' containing 2 lines '000AAA1' and '000AAA2'
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Choose file in 'Barcode file'
- Enter item callnumber between 'ZZZ' and 'ZZZa'
- Check 'Compare barcodes list to results'
- Submit
=> without patch, you get an error trace
- Apply patch, it works
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended commit title.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Starting to replace the ModItem calls with Koha::Item->store
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch makes batchMod.pl and inventory.pl pick the barcode
separators from a new pref BarcodeSeparators (instead of hardcoding
these separators differently).
A few other code locations may be potential candidates for such a change
too.
Test plan:
Test inventory with a few variations of BarcodeSeparators.
Test Batch item modification similarly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
If a barcode contains special characters like $, the regex in inventory
does no longer work.
This fix (as suggested by Jonathan) replaces the regex by a eq compare.
Test plan:
Pick one barcode and add a $ somewhere in the middle, say 123$456.
Include this barcode in a barcode file for inventory.
Run inventory on that file and verify that barcode was read and datelastseen
was updated. The barcode should not be reported as missing (not scanned).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Note: This is here for information purpose, feel free to test it if you
wan to play with it.
TODO: C4::Reserves::_get_itype is not longer in use
No more GetItem must be returned by:
git grep GetItem|grep -v GetItemsAvailableToFillHoldRequestsForBib|grep
-v GetItemsForInventory|grep -v GetItemsInfo|grep -v
GetItemsLocationInfo|grep -v GetItemsInCollection|grep -v
GetItemCourseReservesInfo|grep -v GetItemnumbersFromOrder|grep -v
GetItemSearchField|grep -v GetItemTypesCategorized|grep -v
GetItemNumbersFromImportBatch|cut -d':' -f1|sort|uniq
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
https://bugs.koha-community.org/show_bug.cgi?id=19905
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
To test:
1 - Catalog an item under LCC with callnumber GT95
2 - cn_sort should calculate as GT0095
3 - Go to inventory tool
4 - Enter a range that should have your item e.g LC GT90 to GT100
5 - Item is not returned
6 - Apply patch
7 - Item should be returned
8 - Verify things otherwise work as expected
Signed-off-by: Anne-Claire Bernaudin <anne-claire.bernaudin@univ-rennes1.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
https://bugs.koha-community.org/show_bug.cgi?id=19905
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch enables items to be skipped for inventory stocktaking
if the item is currently a waiting hold. The intention is to skip
items that should be on the holds waiting shelf in the library.
Test Plan:
1) Apply this patch
2) Generate a list of barcodes ordered by callnumber
3) Select one of those items and place it on hold, then confirm the hold
4) Remove that barcode from the list of barcodes
5) Browse to the inventory tool, choose your barcodes file
6) Run the inventory tool with that barcode file.
7) Note the tool says that item should have been scanned
8) Click the browsers back button to return to the previous page
9) Check the checkbox for "Skip copies marked as waiting holds"
10) Run the tool again, not it does not flag that item as previously
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch addes the ability to choose to be warned if it's possible
an item was scanned out of order ( i.e. mis-shelved ).
Test Plan:
1) Apply this patch
2) Generate a list of barcodes ordered by callnumber
3) "Misplace" one callnumber by moving it to another area of the list
4) Browse to the inventory tool, choose your barcodes file
5) Check the checkbox for "Check barcodes list for items shelved out of order"
6) Click "submit", note the item has been flagged as possibly out of order
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
In inventory, optional filters are build from authorize values categories used for items.notforloan, items.itemlost, items.withdrawn and items.damaged.
The bug is that description of value 0 is always "For loan".
This seems to be only for "notforloan".
Second bug is that if a description exists for "notforloan" value 0, it is not used.
This patch corrects by adding "For loan" only for "notforloan" authorized values and if there is no 0 value.
It changes the description added by code from "ignore" to a more unlikly user defined "__IGNORE__".
Test plan:
1) Make sure you have authorized values defined on items.notforloan, say "NFL" category, with at least a value and description but no 0 value
2) Make sure you have authorized values defined on items.itemlost, say "LOST" category, with 0 = "Not lost" and 1 = "Lost"
3) Go to inventory /cgi-bin/koha/tools/inventory.pl
4) Without patch you see "For loan" on both items.notforloan and items.itemlost
5) With patch you see "For loan" only in items.notforloan, you see for items.itemlost : "Not lost" and "Lost"
6) Create in authorized values category "NFL" a value 0 with description "Available"
7) Go to inventory /cgi-bin/koha/tools/inventory.pl
8) Without patch you see "For loan" in items.notforloan for value 0
9) With patch you see "Available" in items.notforloan for value 0
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The same pattern was used in other files, this patch fixes it.
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It was mapped with "lost" instead of "itemlost".
== Test plan ==
1. Have a lost item
2. Go to staff:/cgi-bin/koha/tools/inventory.pl
3. Tick "Optional filters" → "items.itemlost" →
"name of Authorized values for the lost state"
4. Tick "Export to CSV file"
5. Submit
6. Open the CSV
7. Check that the lost item is in the list
8. You should observe that the "Lost status" column is empty for all items
This is the problem
9. Apply this patch
10. Click submit to re-export the CSV
11. Open the CSV
12. Check that the lost item is in the list
13. You should observe that the "Lost status" column now filled with the
expected values.
14. Smile because it works! :D
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Maksim Sen <maksim@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes \n, \r, |, comma, semicolon and hyphen ('-') all valid
separators between barcodes passed to inventory.
An additional grep removes empty barcodes. (Note: The grep looks for at
least one non-whitespace character. We could be more specific, but this
allows for more flexibility like testing with alphanumeric barcodes etc.)
Test plan:
Upload a barcode file that contains various allowed separators.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jenny Way <jwayway@hotmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Inventory tool performance seems to be worst since 16.11.
I think it is because of authorized values computing changed by Bug 17249.
For each subfield of each item, we try to get the authorized value description with Koha::AuthorisedValues->search_by_marc_field.
But this method does not use cache like Koha::AuthorisedValues->get_description_by_koha_field.
I propose to use Koha::AuthorisedValues->get_description_by_koha_field and also to look for authorized value description only for item fields used in TT : location, notforloan, itemlost, damaged, withdrawn.
I have experimented inventory time on 100 items from 5s to 1s.
Test plan :
- Without patch
- Perform inventory with barcode file
- Check results and mesure execution time
- Apply patch
- Reperform inventory with same barcode file
- Check results is the same
- Compare execution time
- Run prove t/db_dependent/Items/GetItemsForInventory.t
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Most of the time C4::Biblio::GetBiblioData is used to retrieve the title
and/or the author of a bibliographic record.
This patch replaces the easy occurrences of GetBiblioData, the ones
where the 2 joins are needed, but only data from biblio and biblioitems
table are.
Test plan:
It will be hard to test everything, I'd suggest a QAer to review this
patch and confirm that the difference occurrences of GetBiblioData have
been correctly replaced by calling Koha::Biblios->find or
$biblio->bibioitem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Currently, the value of compareinv2barcd is used to determine if the
Seen column, the Select/Clear all buttons and the Mark seen buttons are
displayed. But if we scanned barcodes, we already marked items as seen.
So we should only display these buttons when we did not upload barcodes.
Test plan:
[1] Upload a barcode file. Check that the result form does not show
the buttons.
[2] Generate an inventory list, so do not upload a barcode file. Verify
that you still see the buttons.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch contains the following changes:
[01] Label "Inventory date" reworded to "Last inventory date", adding a
small explanation for its purpose.
[02] Restructured the results: it was an array with items and possible
error messages. Multiple messages duplicated individual items. Now the
results are in a hash, pulling all error messages for one item together.
At the end of the script they are copied to an array. (A helper sub
additemtoresults is added in this regard.) We no longer use array
@items_with_problems.
[03] Both datepickers are no longer connected to the same class. This
prevents changing the set date by filling the last inventory date.
[04] Input markseen in the template and $markseen in the script are
no longer needed.
[05] The paragraph before the detail link in the results table in the
Title column has been removed. Same for problems column. This makes
vertical spacing consistent.
[06] Problem status 'missingitem' is no longer used; the missing items
are marked as 'not_scanned'. Two additional statuses are: no_barcode and
checkedout.
[07] Removed unused $itemtype, $totalrecords and $count. We use variable
$moddatecount to report a count to the template.
[08] The script updated scanned items twice. The first time with ModItem
and the second time with ModDateLastSeen. The second call is removed.
[09] If a book is checked in, we do no longer return an error message when
the checkin is successful (ERR_ONLOAN_RET). The updated datelastseen is
passed to the results.
[10] $wrongplacelist is renamed to $rightplacelist. It is only built when
we need it. (Same for inventorylist now.)
[11] Datelastseen (last inventory date) is always used for building the
inventory list. It allows you to process partial barcode lists or make
a list of items not seen after some date. We do no longer use variable
$paramdatelastseen.
[12] The section where items.datelastseen was compared with the inventory
date has been removed. Scanned items were already updated; to get items
seen before some date, you can now use last inventory date without passing
barcodes.
The form can mainly be used for the following three cases:
[1] Prepare an inventory list or csv file; we do not upload barcodes.
[2] Update items for uploaded barcodes without comparing to inventory.
Last inventory date is useless in this case.
Errors wrongplace, checkedout and changestatus are reported.
Use this scenario for partial scanned barcode lists (all but last).
[3] Update items for uploaded barcodes and compare to inventory, filtered
by an optional last inventory date.
Apart from the errors mentioned under [2], this also reports
not_scanned ("missing") and no_barcode.
Use this scenario too for the last partial barcode file (together with
inventory date).
Test plan:
See next patch ("Interface changes").
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On bug 12913 a zero status is added on the inventory form. This prevents
a lot of false warnings for a wrong notforloan status. The zero status
is not included in the default setup. But if you would add one, the
status will display here twice now.
This patch checks if the status already exists.
Test plan:
[1] Add a zero NOTFORLOAN status if it does not yet exist in Authorized
values.
[2] Check that you do not see two "For loan" statuses on inventory form.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The zero status should be added in @notforloans. It is a legitimate status
for available books. The zero status description can be translated in
the template.
The 'Change item status' is confusing. We mean that we saw a notforloan
status that we do not expect (read: does not exist in the table).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In inventory tool, there is a test on scanned items notforloan value : if the value is not one of authorized values, the inventory results displays the problem "Change item status".
The bug is that if notforloan filter is not used, the notforloan values array is not filled and so all scanned items are marked with this problem.
Test plan :
- Check you have in default framework an item subfield mapped with items.notforloan and with an authorized value catergory, for example 'NOTFORLOAN'
- Check the authorized value category has at least value '0'
- Create a new value in this category, for example '9'
- Create a biblio with default framework
- Create an item with barcode='000AAA1', callnumber='ZZZAAA1' and notforloan=0
- Create an item with barcode='000AAA2', callnumber='ZZZAAA2' and notforloan=9
- Delete new value created above, for example '9'
- Create a file 'barecodes.txt' containing 2 lines '000AAA1' and '000AAA2'
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Choose file in 'Barcode file'
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Check 'Compare barcodes list to results'
- Submit
=> without patch, you get 2 results with problem 'Change item status' even for item with notforloan=0
=> with patch, you get 1 result with 'Change item status' on item with notforloan=9
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Koha::getframeworks returned a hashref of biblio frameworks.
It was mainly used to generate the dropdown list of frameworks.
The scripts modified in this patch did not necessary order the element
by description (frameworktext), the displays were not consistent from
one screen to another.
Using the same search method everywhere:
Koha::BiblioFrameworks->search({}, { order_by => ['frameworktext'] });
We will know always get the framework in the same order.
Test plan:
Following the different pages modified by this patch, and make sure the
frameworks are displayed correctly in the dropdown list:
1/ acqui/z3950_search.pl - Create an order from an external source.
2/ admin/fieldmapping.pl - Define some mappings keyword / MARC field
3/ admin/marctagstructure.pl - On the MARC frameworks admin page, select
another framework than the default one and click on the 'Search' button
4/ catalogue/MARCdetail.pl - On the MARC defail page, change the
framework you want to use to display the record
5/ cataloguing/addbiblio.pl - Add or edit a biblio record, change its
framework. When editing, the framework of the record should be selected
by default
6/ cataloguing/addbooks.pl - Go on the cataloguing home page and click
on the "New record" button. You should see all the frameworks
7/ cataloguing/merge.pl - Select 2 biblio records to merge. On the first
step (select the merge reference), you should be allowed to select the
framework to use.
8/ tools/inventory.pl - On the inventory page, the "Item statuses" part
should be populated as before this patch
9/ tools/manage-marc-import.pl - Stage records for import. Before
importing them into the catalog, you should see the framework dropdown
list.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Works Ok.
No errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This subroutine was only used once in GetItemsForInventory.
It can be replaced with a quite simple search on AV join on
authorised_value_categories and marc_subfield_structures tables.
Note that the "interface" parameter was always set to "staff" and was
useless.
Test plan:
Play with the inventory and confirm that the AV descriptions are
correctly displayed.
The tests in t/db_dependent/Items/GetItemsForInventory.t cover this
change and should still pass.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
GetAuthValCode did not return anything if the authorised_value column
was not defined. Our new calls to Koha::MarcSubfieldStructures->search
should behave the same
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Koha::GetAuthValCode returned the authorised value
category for a given kohafield.
This can be acchieve easily using a new Koha::AuthorisedValues->search_by_koha_field
method which will mimic search_by_marc_field.
Test plan:
Confirm that the description is correctly displayed on the following
pages:
- detail and moredetail of a bibliographic page (itemlost, damaged, materials)
- Set AcqCreateItem=ordering and receiving items.
The description for notforloan, restricted, location, ccode, etc.
field should be displayed.
- Items search form
- On the checkout list from the circulation.pl and returns.pl
pages, the description for "materials" should be displayed
Note that GetKohaAuthorisedValuesMapping is going to be removed on bug
17251.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch deals with the inventory files calling
GetKohaAuthorisedValuesFromField.
Test plan:
prove t/db_dependent/Items/GetItemsForInventory.t
should still return green
Use the inventory tool, on the result page the AV descriptions should
correctly replace the codes
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The inventory tools automatically check in items, this patch adds it as
an option.
Test plan:
1/ Check an item out, fill a file with its barcode, and use this file in
the inventory tools.
2/ Check the new checkbox and confirm that the item is not checked in
3/ Repeat again and don't check it, the behavior should be the same as before
this patch.
Signed-off-by: Jason Robb <jrobb@sekls.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Added a missing </li>.
Patch works as expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Most of them were found and fixed using codespell.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
http://bugs.koha-community.org/show_bug.cgi?id=14383
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
After receiving an error while attempt a simple inventory run,
Two lines were changed from:
...$_->...
to
...$item->...
since the loop variable is $item. And $_ is not set to the
expected hash reference, when there is a loop variable.
This also helps explain the "Why are there blank dates on my
last seen field?" problem that has been mentioned by users.
TEST PLAN
---------
1) Apply this patch after a reset to master.
2) Log in to staff client
3) Add one item via z39.50, setting barcode to a known value (BARCODE1)
4) Wait for the reindex
5) Home -> Tools -> Inventory/Stocktaking
6) Browse for a file with the barcode in it
7) Set the library dropdown to the library branch of the added item.
8) Check 'Compare barcodes list to results:'
9) Click 'Submit'
-- This should not die under plack.
This should not generate blank last seen dates.
The last seen dates should be as expected.
10) run koha qa test tools
11) Confirm the two change point correspond to the two change points
in the patch which shall not be pushed to master.
The test result comply with expected outcome outlined in test plan.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
The current code uses
$barcode = <fh>;
logic. This reads until \n, as far as I can tell.
EOL is indicated by \n, \r, and \r\n depending on OS and software.
So, to this end, rather than File::Slurp (which is a potential
memory hog, which is already an issue with no filters), a loop
to pre-read the barcodes was written.
This loop includes:
$barcode =~ s/\r/\n/g;
$barcode =~ s/\n\n/\n/g;
my @data = split(/\n/, $barcode);
push @uploadedbarcodes,@data;
So, that means that lines ending in \n would have it stripped
and pushed into the uploaded barcodes array.
Lines ending in \r would likely be read as one giant block,
have everything converted to single \n's and then using a split,
the set of barcodes are pushed into the uploaded barcodes array.
Lines ending in \r\n would get that stripped and pushed into the
uploaded barcodes array.
It is then the uploaded barcodes array that is looped over for
validating the barcodes.
TEST PLAN
---------
1) Back up your database
2) Download the three sample files (or create your own)
3) Log in to staff client
4) Create a branch with no inventory.
5) Home -> Tools -> Inventory/Stocktaking
6) Browse for your '\r' test file.
7) Limit to just that branch
8) Click 'Submit'
-- Confirm expected errors
9) Repeat steps 5-8 with the '\n' test file.
10) Repeat steps 5-8 with the '\r\n' test file.
-- one of these repetitions should have problems.
11) Apply patch
12) Repeat steps 5-8 for each of the 3 test files.
-- there should be no issues.
13) run koha qa test tools.
Note: This is a tweak based on Jonathan Druart's comment #16
I have reset it to needs sign off again.
Followed test plan. Works as expected. qa OK.
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>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
"item not scanned": when calling GetItemsForInventory, datelastseen should
be used when "compare barcodes list to result" is checked.
Otherwise, when loading multiple barcodes files for the same inventory, many
items will be marked as "item not scanned" when loading the last barcode file
("compare barcodes list to result" checked) even though they were scanned.
"wrong place": when searching for wrongly placed items, we should only check
for the location (callnumbers, location and branch). To fix this, A new call
to GetItemsForInventory has been made with location filters only.
Otherwise, any item with a different itemtype for instance will be marked as
wrong place even if the location is correct.
Test plan:
"item not scanned" status:
1) Split a barcode file in two.
2) Load the first barcode file without checking "compare barcodes list to result".
3) Load the second barcode file with "compare barcodes list to result" checked.
4) Check in the csv report that you have a lot of scanned items with the "item
not scanned" status.
Then apply the patch, do the same, and check that the false "item not scanned"
statuses are gone.
"wrong place" status:
1) Load a barcode file with barcode matching an item that has a correct
location, but a different itemtype than what you're looking for.
2) Check in the results that this item will be marked as "change item status"
and "wrong place".
Then apply the patch, do the same, and check that the only status for this item is "change item status", which is correct.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In inventory results, CSV or screen, the item withdrawn information is missing.
This information can be usefull to understand why an item was not scanned.
Test plan :
- Check you have in default framework an item subfield mapped with items.withdrawn
- Create a biblio with default framework
- Create an item with barcode='000AAA1', callnumber='ZZZAAA1' and withdrawn=0
- Create an item with barcode='000AAA2', callnumber='ZZZAAA2' and withdrawn=1
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Submit
=> You see a column 'Withdrawn' with withdrawn value
- Go to inventory tool : /cgi-bin/koha/tools/inventory.pl
- Enter item callnumber between 'ZZZ' and 'ZZZZ'
- Check 'Export to CSV file'
- Submit
- Open exported file
=> You see a column 'Withdrawn' with withdrawn value
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>
The $lines_read++; was before the code which skipped empty
lines. By moving it after the next unless $barcode; code, the
$lines_read variable only counts potential barcodes, and does
not include empty lines.
TEST PLAN
---------
1) Apply patch.
2) Attempt a valid barcode file with empty lines.
-- The potential barcode count should exclude the empty lines.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Empty lines are now no longer counted as potential barcodes.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The inventory tool had no form of validating on what was assumed
to be a valid barcode number.
To solve this, an extra loop to read before processing was added.
This allows to validate length and content. By using a check
of \p{Print}, this includes Unicode characters such as umlauts,
but excludes unusual control characters.
The template was modified to accomodate validation messages
related to the length and content errors. Additionally, it says
how many "barcodes" were read. Barcodes are supposed to be on
separate lines.
TEST PLAN
---------
1) Attempt to select a file which does not contain barcodes and
is not a text file.
-- a horrible lack of validation and spamminess ensues.
2) Apply patch
3) Create three files.
a) One containing valid barcodes on each line
-- this file should trigger no errors. Attempt a valid
barcode with an umlaut.
b) A copy of the first with an extra line of >20 characters
(e.g. The Quick Red Fox Jumped Over The Brown Fence^A^B^C)
-- this file should trigger the singular error message case.
^A^B^C are actually CTRL-A,CTRL-B,CTRL-C, and it is left
as an exercise to the reader to add them to the line.
c) A copy of the second with the last line duplicated
-- this file should trigger the plural error message case.
4) Attempt each of the three files.
5) Run koha-qa tools.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
I have a feeling that the column size could be better fetched from
Koha::Database. But it is an improvement in functionality signing off
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Passes tests and QA script.
Another thing for another day:
Empty lines are counted for the potential barcodes.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Works as expected, tried with arab strings, umlauts and no regressions found.
This should correct issues with the output_prefs in the
compareinv2bar logic section of tools/inventory.pl
It is a follow up to bug 11253.
TEST PLAN
---------
NOTE: There should be no distinguishable difference before and
after the patch. This corrects a works by accident bug.
Back up DB.
Create a small barcode file from books in a given branch.
Set I18N/L10N system preference of dateformat to mm/dd/yyyy.
Go to inventory/stocktaking tool.
Browse for the barcode file.
Click submit just below the 'Use a barcode file' section.
All looks fine in mm/dd/yyyy format.
Set I18N/L10N system preference of dateformat to yyyy-mm-dd.
Go to inventory/stocktaking tool.
Browse for the barcode file.
Click submit just below the 'Use a barcode file' section.
All looks fine in yyyy-mm-dd format.
Set I18N/L10N system preference of dateformat to dd/mm/yyyy.
Go to inventory/stocktaking tool.
Browse for the barcode file.
Click submit just below the 'Use a barcode file' section.
All looks fine in dd/mm/yyyy format.
Apply patch
Restore DB (so results should be comparable to the first result)
Repeat the three testing blocks above.
There should be no visible difference.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch fixes a stray call to output_pref() that had not been
updated by the patch for 10380, which caused a crash when uploading
a barcode file when the dd/mm/yyyy dateformat is in use.
TEST PLAN
---------
Set I18N/L10N system preference of dateformat to dd/mm/yyyy.
Go to inventory/stocktaking tool.
Browse for the barcode file.
Select the branch (i.e. not All libraries) to match.
Click submit
KABOOM!
Apply patch
Go to inventory/stocktaking tool.
Browse for the barcode file.
Select the branch (i.e. not All libraries) to match.
Click submit
Table displays dates in "Unseen since" column.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Before the patch, I had this error when using dateformat=ddmmyy:
Template process failed: undef error - The 'day' parameter ("2014") to DateTime::new did not pass the 'an integer which is a possible valid day of month' callback at /usr/local/share/perl5/Params/Validate/PP.pm line 633.
This patch corrects the problem.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Confirmed problem before applying the patch. Tested with the
patch all dateformat setting still work correctly.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
