The job reports errors when deleting items.
The issue seems to be that Koha::Object->delete claims in the POD to
return -1, 0, or 1 as a result, but it in fact returns the Object
itself on a successful deletion
The errors are reported as:
ERROR DELETING ITEM 501740: Koha::Item=HASH(0x55ce407a1a78)
To recreate:
1 - Find or create a record with some items
2 - Ensure those items can be deleted (not on loan, etc.)
3 - Edit the record leader and set position 5 to 'd'
4 - perl misc/cronjobs/delete_records_via_leader.pl -i -v --confirm
5 - Deletion succeeds, but reports failure on items
6 - Apply patch
7 - Find or create a new record as above, but this time add an
additional item and check it out to a patron
8 - perl misc/cronjobs/delete_records_via_leader.pl -i -v
9 - Test mode should report 1 item to be deleted, one with error
10 - perl misc/cronjobs/delete_records_via_leader.pl -i -v --confirm
11 - One item should be deleted, one item not, record not deleted
12 - check the item in
13 - perl misc/cronjobs/delete_records_via_leader.pl -i -v --confirm
14 - Successful deletion with no error reported
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
Have a record with the 000 position 5 set to "deleted" (record status)
Use koha-shell to run the job with the -i flag: perl misc/cronjobs/delete_records_via_leader.pl -c -i -v
* items and the record should be deleted
Mark another record with the 000 position 5 set to deleted (record status)
Use koha-shell to run the job without the -i flag: perl misc/cronjobs/delete_records_via_leader.pl -c -v
* if the record had items, it will not be deleted
* if the record did not have items, it will be deleted.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch change Koha::Cron to be a more generic Koha::Script class and
update all commanline driven scripts to use it.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds 'cron' as a valid interface and sets it appropriately for
existing cron scripts.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes the code using Koha::Biblio::Metadata->marcflavour use
->schema instead for all interactions.
To test:
- Update the DB structure:
$ updatedatabase
- Update the schema files:
$ dbic
- Notice all the places in which biblio_metadata is used
$ cd kohaclone
$ git grep biblio_metadata
=> SUCCESS: They all use `schema` instead of marcflavour
- Notice all the places that use Koha::Biblio::Metadata:
$ git grep Koha::Biblio::Metadata
=> SUCCESS: They all use the schema attribute when they used to use
marcflavour
- Run all the modified tests and scripts
=> SUCCESS: We are all good
- Sign off :-D
Note: while this seems like a minor change, the places in which plain
SQL is used really require understanding the queries and how they are
used, because some query results might be passed to some other method
that in turn uses the marcflavour attribute. I of course took that into
account but errare humanum est :-D
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
perl misc/cronjobs/delete_records_via_leader.pl
=> Should display a warning
perl misc/cronjobs/delete_records_via_leader.pl --test
=> Should not display a warning and script should not apply changes
perl misc/cronjobs/delete_records_via_leader.pl --confirm
=> Should not display a warning and script should apply changes
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.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: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: Using items from Koha::Biblio seems better :)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Two discussions on koha-devel lead to the same conclusion:
biblioitems.marcxml should be moved out this table
- biblio and biblioitems
http://lists.koha-community.org/pipermail/koha-devel/2013-April/039239.html
- biblioitems.marcxml & biblioitems.marc / HUGE performance issue !
http://lists.koha-community.org/pipermail/koha-devel/2016-July/042821.html
There are several goals to do it:
- Performance
As Paul Poulain wrote, a simple query like
SELECT publicationyear, count(publicationyear) FROM biblioitems GROUP BY publicationyear;
takes more than 10min on a DB with more than 1M bibliographic records
but only 3sec (!) on the same DB without the biblioitems.marcxml field
Note that priori to this patch set, the biblioitems.marcxml was not
retrieved systematically, but was, at least, in
C4::Acquisition::GetOrdersByBiblionumber and C4::Acquisition::GetOrders
- Flexibility
Storing the marcxml in a specific table would allow use to store several
kind of metadata (USMARC, MARCXML, MIJ, etc.) and different formats (marcflavour)
- Clean code
It would be a first step toward Koha::MetadataRecord for bibliographic
records (not done in this patch set).
Test plan:
- Update the DBIC Schema
- Add / Edit / Delete / Import / Export bibliographic records
- Add items
- Reindex records using ES
- Confirm that the following scripts still work:
* misc/cronjobs/delete_records_via_leader.pl
* misc/migration_tools/build_oai_sets.pl
- Look at the reading history at the OPAC (opac-readingrecord.pl)
- At the OPAC, click on a tag, you must see the result
Note: Changes in Koha/OAI/Server/ListRecords.pm is planned on bug 15108.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Zeno Tajoli <z.tajoli@cineca.it>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Fix record matching in misc/cronjobs/delete_records_via_leader.pl
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Recently added, delete_records_via_leader.pl reads biblioitems.marc as a
text field and search for record to delete regarding the leader 5.
This can be acchieve doing the same thing on biblioitems.marcxml (will
certainly be slower) waiting for a patch on bug 15537.
Test plan:
Confirm that this script works as before, to do so the easiest way would
be to dump your DB before executing the update DB entry, execute the
script to delete records, reinsert the DB, execute the udpate DB entry
(remove biblioitems.marc), execute the script to delete records.
You should get the same number of records deleted.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Position 05 of the leader in MARC 21 indicates the record's status.
A lower case 'd' indicates that the record is to be deleted
(http://www.loc.gov/marc/authority/adleader.html).
This patch adds a cronjob script that may be run nightly to delete
records where position 05 of the leader is set to 'd'.
Test Plan:
1) Edit one or more records, and set the leader position 05 to 'd'.
2) Run misc/cronjobs/delete_records_via_leader.pl -c -v
3) Those records should either be deleted, or an error message should
state why they were not.
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Works as advertised. Edited a record with an item to have leader05 = d,
then ran delete_records_via_leader.pl with -c and got a message that
the record could not be deleted because of the item. Removed the item
and the script deleted the record. Tried with another record with an
item, this time with the -i option and the record was deleted.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
