Test plan:
Run background job tests. Especially the changed one.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
All test pass when running this:
prove t/db_dependent/Koha/BackgroundJobs*
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(cherry picked from commit 291268f318)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the current background jobs classes use the added
helpers in order to simplify them.
No behavior change is expected.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Rebased-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Ther are options that allow avoiding marking an issue returned when se tot lost.
Libraries do this to tie a lost item to a patron clearly.
Eventually, after the patron has paid, or after some time, the library may wish
to delete the item. When doing so, they do not wish to check the item in and affect any statuses
or fines. This is also true for withdrawn items
It would be helpful to have a way to mark issues returned in bulk, when they have not been marked
returned in the past
To test:
1 - Apply patches
2 - Restart all
3 - Set 'MarkLostItemsAsReturned' system preferences to 'None'
4 - Check out some items that have replacement fees set
5 - Mark them lost
6 - Check out more items, mark them withdrawn
7 - Set system preference 'BlockReturnOfWithdrawnItems' to block
8 - Enter item barcodes into batch modification
9 - Leave 'Mark items returned as blank
10 - Verify nothing was checked in
11 - Repeat but set 'Mark items as returned' to 'No'
12 - Verify nothing was checked in
13 - Repeat, but set 'Mark items as returned' to 'Yes'
14 - Verify items are returned
15 - Verify no fines have been adjusted
16 - Verify withdrawn items are sitll withdrawn
17 - Verify you can now delete the items
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We are sending "queue" as parameter, but "job_queue" is retrieved in
Koha::BackgroundJob->enqueue...
Test plan:
Read code and confirm the above.
More fun for test plan will be found on bug 32393
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Making the disabling utf8 flag explicit instead of depending on
the default of the CPAN module.
Incorporating the change in background_jobs_worker too.
Test plan:
See next patches when we look at unit tests.
Restart koha-worker.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Our database connections have been set up so that they will
automatically convert perl encoded strings to utf8 encoded strings
when sending data to database tables and decode the utf8 encoded
strings from the tables back to internal perl strings. As we can see
from a call in Koha/BackgroundJob.pm we are encoding the perl internal
string to utf8 and then decoding it back to perl internal string:
my $data_dump = decode_json encode_utf8 $self->data;
We can skip this unnecessary encode<->decode step (as the database
object has done the decoding for us) by simply calling the
JSON->new->decode() method which doesn't perform any string decoding.
Furthermore, the original code was buggy and didn't always remember to
encode the unencoded strings, in Koha::BackgroundJob::process we can
see
my $context = decode_json($self->context);
is missing the encode step. Now after this change encoding before
decoding is not necessary as we are using the methods from the JSON
module that do not perform any transcoding.
Note to those concerned whether the old data in the database is
compatible with this new code:
Luckily our database connection object seems to be smart and
didn't utf8 encode the utf8 returned data from the old encode_json()
calls (probably checks the utf8 flag for the string (Encode::is_utf8($str))).
To test whether this fixes the original bug reported of not being able
to schedule background jobs with koha user having non-ASCII letters in
their surname:
1) Change your staff users surname/lastname to "ääää"
2) Log out and back in.
3) Go to a biblio record detail page and click "Select all" in the
items table
4) Click Delete selected items and proceed with the deletion
5) Notice the batch item deletion job has failed status
6) Apply patch and repeat but this time the deletion job should finish.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Andrew <andrewfh@dubcolib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch renames the queues so the default is the **real-time** one, and
the other (*long_tasks*) is kept for **long running** tasks.
All current *batch* tasks are explicitly assigned to the **long_tasks**
queue as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Now $self is actually an instance of the job class, there's no need to
have the job_id parameter passed, or the have the ->process method
re-fetch the object from the database.
This patch cleans things up.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It makes more sense to commit when an item has successfully been modified and
so move the transaction inside the loop.
It also fixes the progress of the whole job.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Here we go!
Disclaimer: this patch is huge and does many things, but splitting it in
several chunks would be time consuming and painful to rebase. However it
adds many tests and isolate/refactor code to make it way more reusable.
This patchset will make the "batch item modification" and "batch item
deletion" features use the task queue (reminder: Since bug 28158, and so
21.05.00, we do no longer use the old "background job" functionality and
the user does not get any info about the progress of the job).
More than that, more of the code to build an item form and a list of
items is now isolated in module (.pm) and include files (.inc)
We are reusing the changes made by bug 27526 that simplifies the way we
edit/create items (no more unecessary serialization Koha > MARC > MARCXML
> XML > HTML)
New module:
* Koha::BackgroundJob::BatchDeleteItem
Subclass for process item deletion in batch
* Koha::BackgroundJob::BatchUpdateItem
Subclass for process item modification in batch
* Koha::Item::Attributes
We needed an object to represent item's attributes that are not
mapped with a koha field (aka "more subfields xml")
This module will help us to create the marcxml from a hashref and the
reverse.
* Koha::UI::Form::Builder::Item
The code that was used to build the add/edit item form is
centralised in this module. In conjunction with the
subfields_for_item BLOCK (from html_helpers.inc) it will be really
easy to reuse this code in other places where the item form is used
(acquisition and serials modules)
* Koha::UI::Table::Builder::Items
Same as previously for the table. We are now using this table from 3
different places (batch item mod, batch item del, backgroung job
detail view) and the code is only in one place.
To use with items_table_batchmod BLOCK (still from html_helpers.inc)
This patch is fixing some bugs about repeatable subfields and regex. A UI
change will reflect the limitation: if you want to apply a regex on a
subfield you cannot add several subfields for the same subfield code.
Test plan:
Prepare the ground:
- Make sure you are always using a bibliographic/item record using the framework
you are modifying!
- Add some subfields for items that are not mapped with a koha field
(note that you can use 'é' for more fun, don't try more funny
characters)
- Make some subfields (mapped and not mapped with a kohafield)
repeatable
- Add default values to some of your subfields
There are 4 main screens to test:
1. Add/edit item form
The behaviour should be the same before and after this patch.
See test plan from bug 27526.
Those 2 prefs must be tested:
* SubfieldsToAllowForRestrictedEditing
* SubfieldsToUseWhenPrefill
2. Batch modification
a. Fill some values, play with repeatable and regex.
Note that the behaviour in master was buggy, only the first value was modified by the regex:
* With subfield = "a | b"
1 value added with "new"
=> "new | b"
* With subfield = "a | b"
2 new fields "new1","new2"
=> "new2 | b"
Important note: For repeatable subfields, a regex will apply on the subfields in
the "concatenated form". To apply the regex on all the different subfields of a given
subfield code you must use the "g" modifier.
This could be improved later, but keep in mind that it's not a regression or behaviour
change.
b. Play with the "Populate fields with default values from default framework" checkbox
c. Use this tool to modify items and play with the different sysprefs that
interfer with it:
* NewItemsDefaultLocation
* SubfieldsToAllowForRestrictedBatchmod
* MaxItemsToDisplayForBatchMod
* MaxItemsToProcessForBatchMod
3. Batch deletion
a. Batch delete some items
b. Check items out and try to delete them
c. Use the "Delete records if no items remain" checkbox to delete
bibliographic records without remaining items.
d. Play with the following sysprefs and confirm that it works as
expected:
* MaxItemsToDisplayForBatchDel
e. Stress the tool: Go to the confirmation screen with items that can be
deleted, don't request the job to be processed right away, but check the
item out before.
4. Background job detail view
You must have seen it already if you are curious and tested the above.
When a new modification or deletion batch is requested, the confirmation
screen will tell you that the job has enqueued. A link to the progress
of the job can be followed.
On this screen you will be able to see the result of the job once it's
fully processed.
QA notes:
* There are some FIXME's that are not blocker in my opinion. Feel free to
discuss them if you have suggestions.
* Do we still need MaxItemsToProcessForBatchMod?
* Prior to this patchset we had a "Return to the cataloging module" link
if we went from the cataloguing module and that the biblio was deleted.
We cannot longer know if the biblio will be deleted but we could display
a "Go to the cataloging module" link on the "job has been enqueued"
screen regardless from where we were coming from.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Marcel de Rooy
Tomas Cohen Arazi
Nick Clemens
Jonathan Druart
Joonas Kylmälä