Test plan, on k-t-d
1) Go to 'my account' on top right user menu
2) On 'Patron messaging preferences', click 'Edit'
3) On the 'Item due' row, check the 'Email' and 'Digests only' checkboxes and save
4) On the top search bar, press 'Check out' and enter '42' (koha user cardnumber)
5) On the checkout input bar, enter 39999000001372 and press checkout
7) Go to 'Set library' on top right user menu and pick a different library
8) Repeat step 4), then, on the checkout input, enter 39999000004571 and press checkout
9) Verify that this user now has 2 items checked out, from 2 different libraries at /cgi-bin/koha/circ/circulation.pl?borrowernumber=51
9) Run the following 2 queries to force the due_date to be equal to 'today's' date for both issues:
NOTE: change the YYYY-MM-DD below to whatever day it is you're running this test plan
UPDATE issues SET date_due = '2023-06-19 23:59:00' where issue_id = 1;
UPDATE issues SET date_due = '2023-06-19 23:59:00' where issue_id = 2;
10) Run the cronjob:
./koha/misc/cronjobs/advance_notices.pl -c --digest-per-branch
11) Verify that two DUEDGEST notices were created, one per each library, but both notices contain both issues:
SELECT letter_code, time_queued, content FROM message_queue ORDER BY message_id DESC LIMIT 2;
12) Apply patch, then do 10) and 11) again
13) Verify that each notice only contains the issue for its respective library
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Stephen Graham <s.graham4@herts.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 39e6b100cb)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch carries this fix into the misc/cronjobs/recalls/expire_recalls.pl cronjob so that recalls are automatically expired when they have been waiting a problematic number of days, not considering hours, as expected.
To test, follow the test plan from the first patch. This will set you up with a waiting problematic recall.
Run the cronjob manually
perl misc/cronjobs/recalls/expire_recalls.pl
Refresh your 'Recalls awaiting pickup' page. Your problematic recall should be gone/expired.
Expiration dates will apply when expiring any 'unfulfilled' recall i.e. newly requested, overdue to be returned, and awaiting pickup.
Sponsored-by: Auckland University of Technology
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 0d2052088e)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This includes Jonathan's followup
If cronjobs/fines.pl is running during circulation hours, then an issue may
be considered for having it's overdue fine updated after the issue has been
returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In
this case UpdateFine will create a duplicate fine because it can't find the
specific accountline for the (formerly) overdue issue.
This changes cronjobs/fines.pl to double check the issue before updating
the fine. If the issue has changed between starting the script and updating
the fine, then the script will skip it.
There is a small amount of time between the check and calling UpdateFine
where the issue can be changed and this problem can reoccure. The chance
of that happening is so small that it's probably fine to leave as is.
It is also possible that the fine won't be updated because the issue was
returned. In this case the fine payed by the patron will be lower, but that
is better then the patron finding later that there is more to a fine they
thought they had paid all of.
Test plan (by Caroline):
0. Preliminary settings
0.1. finesMode system preference must be set to Calculate and charge
0.2. There must be a circulation rule that will charge fines (beware of bug 32271)
0.3. In Tools > Calendar, today must not be a holiday
1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2
1.1. Enable batch checkouts
1.1.1. Go to Administration > Global system preferences
1.1.2. Search for BatchCheckouts
1.1.3. Set BatchCheckouts to Allow
1.1.4. Select all categories in BatchCheckoutsValidCategories
1.1.5. Click "Save all Circulation preferences"
1.2. Get a list of barcodes
1.2.1. Go to Reports
1.2.2. Click "Create from SQL"
1.2.3. Give the report a name
1.2.4. For the SQL query, enter
SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60;
1.2.5. Click "Save report"
1.2.6. Click "Run report"
1.2.7. Click "Download" > "Tab separated text"
1.3. Go to a patron's file
1.3.1. Go to Patrons
1.3.2. Click on "Search"
1.3.3. Click on a patron's name
1.4. Do a batch checkout with a due date in the past
1.4.1. Click on the "Batch check out" tab on the left
1.4.2. In "Use a file", click "Choose file"
1.4.3. Choose the file downloaded from the report
1.4.4. In "Hard due date", choose a date in the past
1.4.5. Click "Check out"
1.4.6. Click "Checkout or renew"
2. Find the last issue in the database
2.1. In the database (or in reports), type the following query
SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G;
2.2. Copy the barcode from the last entry
3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time)
3.1. In Koha, click the "Check in" option in the search bar at the top of the page
3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY
3.3. In a terminal, enter the fines.pl command
./misc/cronjobs/fines.pl
3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item
4. Check the patron's fines
4.1. Click on the patron's name in the check in screen
4.2. Go to the Accounting tab on the left
4.3. In the search box just above the table, paste in the returned item's barcode
--> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time
--> With the patch, there is only one fine, Fine (Returned)
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 7e1104da83)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan, on k-t-d
1) Go to 'my account'
2) On 'Patron messaging preferences', click 'Edit'
3) On the 'Item due' row, check the 'Email' and 'Digests only' checkboxes and save
4) On the top search bar, press 'Check out' and enter '42' (koha user cardnumber)
5) On the checkout input bar, enter a barcode e.g. 39999000001372 and press checkout
6) Run the following query to force the due_date to be equal to 'todays' date:
NOTE: change the YYYY-MM-DD below to whatever day it is you're running this test plan
UPDATE issues SET date_due = '2023-06-05 23:59:00' where issue_id = 1;
7) Run the cronjob:
./koha/misc/cronjobs/advance_notices.pl -c --digest-per-branch
8) Notice it hangs, it's stuck on an infinite loop on the 2nd while cycle after if ()
9) Cancel the cronjob script, apply patch
10) Run the cronjob script again (step 7), notice it finishes
11) Access patron's notices:
/cgi-bin/koha/members/notices.pl?borrowernumber=51
Check that the 'Item due reminder' notice is there.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit fac7bb247a)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1. Verify in "About" page that SMS::Send is installed.
If not, install it.
2. Set system preferences:
- SMSSendDriver = 'Test'
- MembershipExpiryDaysNotice = 30
3. In "Notices and Slips" tool, edit the 'MEMBERSHIP_EXPIRY' letter and
verify that both email and sms parts are filled. Use a different
title and body for the sms part
4. Create a new borrower with an email address and an SMS number. Set
their expiry date to a date next week
5. Run misc/cronjobs/membership_expiry.pl --confirm
6. Verify in the patron "Notices" tab that two notices are pending, one
for email, one for sms
Sponsored-by: Médiathèque de Montauban
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1) Run the following test and make sure all pass:
t/db_dependent/api/v1/biblios.t
t/db_dependent/api/v1/checkouts.t
t/db_dependent/api/v1/return_claims.t
t/db_dependent/Circulation/CalcDateDue.t
t/db_dependent/Circulation/CheckIfIssuedToPatron.t
t/db_dependent/Circulation/dateexpiry.t
t/db_dependent/Circulation/GetPendingOnSiteCheckouts.t
t/db_dependent/Circulation/GetTopIssues.t
t/db_dependent/Circulation_holdsqueue.t
t/db_dependent/Circulation/IsItemIssued.t
t/db_dependent/Circulation/issue.t
t/db_dependent/Circulation/MarkIssueReturned.t
t/db_dependent/Circulation/maxsuspensiondays.t
t/db_dependent/Circulation/ReturnClaims.t
t/db_dependent/Circulation/Returns.t
t/db_dependent/Circulation/SwitchOnSiteCheckouts.t
t/db_dependent/Circulation.t
t/db_dependent/Circulation/TooMany.t
t/db_dependent/Circulation/transferbook.t
t/db_dependent/DecreaseLoanHighHolds.t
t/db_dependent/Holds/DisallowHoldIfItemsAvailable.t
t/db_dependent/HoldsQueue.t
t/db_dependent/Holds/RevertWaitingStatus.t
t/db_dependent/Illrequests.t
t/db_dependent/ILSDI_Services.t
t/db_dependent/Items.t
t/db_dependent/Koha/Account/Line.t
t/db_dependent/Koha/Acquisition/Order.t
t/db_dependent/Koha/Biblio.t
t/db_dependent/Koha/Holds.t
t/db_dependent/Koha/Items.t
t/db_dependent/Koha/Item.t
t/db_dependent/Koha/Object.t
t/db_dependent/Koha/Patrons.t
t/db_dependent/Koha/Plugins/Circulation_hooks.t
t/db_dependent/Koha/Pseudonymization.t
t/db_dependent/Koha/Recalls.t
t/db_dependent/Koha/Recall.t
t/db_dependent/Koha/Template/Plugin/CirculationRules.t
t/db_dependent/Letters/TemplateToolkit.t
t/db_dependent/Members/GetAllIssues.t
t/db_dependent/Members/IssueSlip.t
t/db_dependent/Patron/Borrower_Discharge.t
t/db_dependent/Patron/Borrower_PrevCheckout.t
t/db_dependent/Reserves/GetReserveFee.t
t/db_dependent/Reserves.t
t/db_dependent/rollingloans.t
t/db_dependent/selenium/regressions.t
t/db_dependent/SIP/ILS.t
t/db_dependent/Holds.t
t/db_dependent/Holds/LocalHoldsPriority.t
t/db_dependent/Holds/HoldFulfillmentPolicy.t
t/db_dependent/Holds/HoldItemtypeLimit.t
t/db_dependent/Circulation/transferbook.t
2) Performe one or more checkouts for a patron, making sure
that the circulation rules allows for renewals (for example by
setting an earlier due-date).
3) Log in as this patron in OPAC and make sure the list of
checkouts is displayed correctly, and that renewing an issue
still works.
Sponsored-by: Gothenburg University Library
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
C4::Log::cronlogaction() takes a hashref as argument, with "info"
and possibly "action" as keys. But there are a couple of places
where it is called with just a string as argument, and that does
not work. Both places need lock_exec to fail to trigger the error.
I have seen this on a production server, but not been able to
reproduce in ktd.
To test:
- Run this on the Koha repo: grep -r "cronlogaction(" *
- Verify that fines.pl and process_message_queue.pl are the only
scripts that call cronlogaction without a hashref as argument,
but do it like this: cronlogaction( $message );
- Apply this patch
- Run the grep again and verify that all calls to cronlogaction
now take a hashref as argument
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The automatic_renewals.pl cron script currently loops through items for automatic renewal and calls the indexer for each one individually. skip_record_index has now been added as a parameter to the AddRenewal function to skip the indexing process. The item numbers are now added to an array and then the indexer is called once from within automatic_renewals.pl and passed the array to queue one indexing job instead of multiple jobs.
Test plan:
1) AddRenewal uses Koha::Items->store() to trigger the indexing process. Run prove -vv t/db_dependent/Koha/SearchEngine/Indexer.t and check tests 5,6,29,30. These tests prove whether passing skip_record_index to store() triggers or skips the indexing process. All four tests should pass to show that skip_index_records can prevent the indexing being triggered.
2) Add multiple renewals that are able to be autorenewed and run the automatic_renewals.pl script. There should be multiple items queued in zebraqueue.
3) Apply patch and try again
4) There should now only be one job queued in zebraqueue
Mentored-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Add --log-action parameter to cleanup_database.pl
Test plan:
1. Apply patch
2. Enable cataloguing and borrowers log
3. Make some changes to borrowers, create some borrowers, and edit some
biblio records
4. Change the action_logs.timestamp for all action_logs entries to 367
days ago
5. Run cleanup_database.pl with --logs 365 --log-module=MEMBERS
--log-action=CREATE --confirm
6. Confirm only the borrowers creation action_logs entries are removed
7. Run cleanup_database.pl with --logs 365
8. Confirm all action_logs entries are removed
Sponsored-By: Toi Ohomai Institute of Technology, New Zealand
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If you have EmailOverduesNoEmail = Send and specify "--html somedir",
overdue_notices.pl will send a file by email that contains partial
HTML, as a file called attachment.txt. This patch fixes that.
To reproduce in koha-testing-docker:
- EmailOverduesNoEmail = Send
- Make sure you have a loan that was due yesterday, by backdating the
due date
- Set up an overdue action to send "Overdue Notice" (ODUE) to the
category you made the loan to above, when a loan is one day overdue
- Run this command:
$ sudo koha-shell -c "perl misc/cronjobs/overdue_notices.pl -v -t -html /tmp/" kohadev
- Look at the file /tmp/notices-<DATE>.html and make sure it is a full
HTML document, with <html>, <head>, <body> etc.
- Create a report like this:
SELECT message_id, letter_id, borrowernumber, subject, CONCAT( '<pre>', content, '</pre>' ) AS content,
metadata, letter_code, message_transport_type, time_queued, updated_on, to_address, content_type, failure_code
FROM message_queue
WHERE subject = 'Overdue Notices'
ORDER BY message_id DESC
- Run the report and verify there is a line like this in the "content"
of the newest message:
Content-Type: text/plain; name=attachment.txt
- A part of the "content" will be a block of several lines of gibberish
(base64) that look something like "RGVhciAga29oYSwNCg0KQWN...". Copy
this block of text to somewhere like base64decode.org and decode the
text. You should see a fragment of HTML, without <html>, <head>,
<body> etc.
To test:
- Apply the patch
- Run overdue_notices.pl again, with the same arguments as above
- Make sure /tmp/notices-<DATE>.html is still a full HTML document
- Re-run the report, and make sure you now have this in the "content":
Content-Type: text/html; name=attachment.html
- Decode the base64 and make sure it is now a full HTML document, with
<html>, <head>, <body> etc.
- Re-run overdue_notices.pl as above, but replace "-html /tmp/" with
"-csv /tmp/test.csv"
- Make sure /tmp/test.csv and the decoded base64 from the report
contains CSV data
- Re-run overdue_notices.pl as above, but replace "-html /tmp/" with
"-text /tmp/"
- Make sure /tmp/notices-<DATE>.txt and the decoded base64 from the
report contains no HTML
Note:
- The actual text from the different messages will be enclosed in
<pre>-tags
- If you have HTML in your ODUE message template and run with -v, you
will have warnings saying "The following terms were not matched and
replaced"
These are due to Bug 14347, and are not adressed by the current patch.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds a reaosn parameter and passes it into the cancellation if supplied
To test:
1 - Place a hold for a patron in your system
2 - Run script with --days 0 -v
3 - verify that it would cancel the reserves (and that you are okay with cancelling the ones it found)
4 - Make sure you have a notice in the holds module with code 'HOLD_CANCELLATION'
5 - Set content of the notice like:
[% IF hold.cancellation_reason=='too_old' %]
Canceled old
[% END %]
6 - Run script with --days 0 -v --reason too_bad -c
7 - Confirm hold cancelled, no notice sent to patron
8 - Place another hold
9 - Run script with --days 0 -v --reason too_old -c
10 - Confirm hold cancelled, notice sent to patron
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch now checks the status of messages and ignores any message
with a status of 'new'. It is also rebased to account for changes made
to cleanup_database.pl in bug 17350.
Test plan:
1) Ensure you have some EDI orders or even just some dummy messages in the edifact_messages table with a mixture of statuses including 'new'
2) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose (Change the number of days according to the data in your table)
3) The response should show a number of messages that would have been deleted
4) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose --confirm
5) The response should now show the same number of messages have been deleted
6) Check your edifact_messages table to confirm that the data has been deleted
7) Confirm that no messages marked 'new' have been deleted
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Changes a few occurrences of edifact in the output messages
to EDIFACT.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows users to clear out old edifact_messages using the cleanup_database script. The number of days can either be set in the CLI or the default value of 365 can be used.
Test plan:
1) Ensure you have some EDI orders or even just some dummy messages in the edifact_messages table
2) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose (Change the number of days according to the data in your table)
3) The response should show a number of messages that would have been deleted
4) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose --confirm
5) The response should now show the same number of messages have been deleted
6) Check your edifact_messages table to confirm that the data has been deleted
Sponsored-by: PTFS Europe
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It would be very useful to be able to tell process_message_queue.pl to skip processing some messages. This is particularly useful where a plugin handles sending some message using the before_send_messages hook, but while that plugin is processing, more messages meant for the plugin might be queued. At that point, control moves back to the script and SendQueuedMessages is called, and those messages end up being processed there instead of by the plugin.
Test Plan:
1) Apply this patch
2) Queue two messages, each with a unique word
3) Run process_message_queue --where "content NOT LIKE '%WORD%'"
where WORD is a unique word in one of the two message
4) Note the message containing "WORD" was not processed
5) prove t/db_dependent/Letters.t
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This amends the documentation of the cleanup_database.pl script
to include a hint for how the saved reports data is created.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
apply patch
1 - have or create a report
2 - run your report via the command line with --store-results. Do this twice.
3 - update the saved_reports table to set date_run for one of your two saved results set to a datetime more than 5 days ago
4 - perl misc/cronjobs/cleanup_database.pl --reports 5 --verbose --confirm
5 - Koha tells you its deleting saved reports data from more than 5 days ago
6 - confirm in the database and the staff interface that it's done so
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some of our scripts have a space in the "shebang" (first) line:
#! /usr/bin/perl
This is not illegal, and it does work, but it is good to be
consistent, so this patch removes the space.
To test:
- Run: grep -rn --include=*.pl '#! /usr/' *
- See the list of files that have a space in the shebang
- Apply the patch
- Run the command again, there should be no output, meaning there
are no more files with space in the shebang
- Have a look at the patch and check that it only changes the
shebangs
- Sign off
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: Kyle, stop impersonating John Doe
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Adapted test plan:
1) Apply this patch
2) For DUE and PREDUE notices, set the message body to the following:
Title: [% checkout.title %]
3) For DUEDGST and PREDUEDGST notices, set the message body to the following:
Titles:
[% FOREACH c IN checkouts %]
* [% c.title %][% END %]
4) Generate PREDUE and DUE notices for patrons including digests
5) Verify those notices contain the checkout titles
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: tcohen renamed @issues => @checkouts as well
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Remove loops that only operate one one result only
Signed-off-by: Felicity Brown <Felicity.Brown@montgomerycountymd.gov>
Signed-off-by: George Veranis <gveranis@dataly.gr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Predue / due notices are limited to using itemscontent to display checkouts data. It would be nice to make all the checkouts data available for those notices so that libraries could format that data more nicely if they wish.
1) Apply this patch
2) For DUE and PREDUE notices, set the message body to the following:
Title: [% issue.title %]
3) For DUEDGST and PREDUEDGST notices, set the message body to the following:
Titles:
[% FOREACH i IN issues %]
* [% i.title %]
[% END %]
4) Generate PREDUE and DUE notices for patrons including digests
5) Verify those notices contain the checkout titles
Signed-off-by: Felicity Brown <Felicity.Brown@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows for selection of framework to use when overlaying
records - by default it is set to keep the initial framework
To test:
1 - Create some records using one framework
2 - Export the records
3 - Edit the records to add fields not in original framework
4 - Stage records using a rule that will find matches
5 - Import
6 - Note records contain new fields on display, but they are lost on edit
7 - Apply patch
8 - Stage records again
9 - Select a framework that contains the new fields on import
10 - Import records
11 - Note records now use selected framework and are displayed/edited
correctly
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>
Bug 29788 inadvertantly replaced a call to safe_delete() with safe_to_delete()
such that any time the script should delete an item it only checks to see if
the item is delectable, after which deletion of the record fails because the
items were not deleted.
Test Plan:
1) Mark a record with items to be deleted via the record leader
2) Run delete_records_via_leader.pl -i -b -v
3) Note the script says it is deleting the items but then the record
deletion fails. Note the items remain in the items table of the
database.
4) Apply this patch
5) Repeat step 2
6) This time the items and record should be deleted!
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 script has a pattern to delete rows depending on a given
date/number of days, we should use the filter_by_last_update
Koha::Objects method.
No need for another method and tests, everything is already tested
there.
This patch also suggests to rename the reference to "background" and
"bg" with "jobs", which seems more appropriate and not an abbreviation
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There as a mismatch between the parameter name in documentation (bg-days)
and what was checked in the code (bg-jobs). This makes both match.
To test:
* Apply patch
* Make sure you have some background_jobs older than one day
* Verify the help of the script documents the parameter bg-days
* Run the cleanup_database.pl job
Example: ./misc/cronjobs/cleanup_database.pl --bg-days --confirm -v
* Verify there are no errors and the lines have been deleted as expected
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The TooMany() function and fine calculation functions were incorrectly
hard coded to use homebranch for fetching the circulation rules. Those
ignored completely the syspref HomeOrHoldingBranch where the user
might have set it to holdingbranch and therefore the fines and whether
patron has too many checkouts (TooMany()) were counted using the
unintended branch's rules. This problem only arises in the cases where
there are branch specific circulation rules defined.
Test plan:
1. Make sure following tests pass:
$ prove t/db_dependent/Circulation/_CalculateAndUpdateFine.t
$ prove t/db_dependent/Circulation/TooMany.t
Test plan for fines.pl:
1. Add branch specific fine rules for branches A and B. A having a
fine of 1 per day and B having a fine of 0 per day.
2. Set sysprefs:
CircControl = the library the items is from
finesMode = Calculate and charge
HomeOrHoldingBranch = holdingbranch
3. Create an item with home and holding branch of A
4. Checkout the item with a due date in the past (the past due date can be
specified by clicking "Checkout settings" in the checkout page) and
make sure the branch you are checking from is B.
5. Run perl /usr/share/koha/bin/cronjobs/fines.pl
6. Notice that fines have popped up now to the patron incorrectly
7. Apply patch
8. Pay fines, Check-in the item and check it out again
9. Run perl /usr/share/koha/bin/cronjobs/fines.pl
10. Notice that fine is now 0. This means that the branch
B (holdingbranch of the checked-out item) specific rule is used.
Test plan for staticfines.pl:
1. Add branch specific fine rules for branches A and B. A having a
fine of 1 per day and B having a fine of 0 per day.
2. Set sysprefs:
CircControl = the library the items is from
finesMode = Calculate and charge
HomeOrHoldingBranch = holdingbranch
3. Create an item with homebranch A and holding branch of A
4. Checkout the item with a due date in the past (the past due date can be
specified by clicking "Checkout settings" in the checkout page) and
make sure the branch you are checking from is B.
5. Run perl staticfines.pl --library A --library B --category <PATRONS_CATEGORYCODE>
and notice that now there is inccorectly fines
6. Apply patch
7. Pay fines, Check-in the item and check it out again
8. Run perl staticfines.pl --library A --library B --category <PATRONS_CATEGORYCODE>
and notice the fines are now not generated
Rebased-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
- Run "perldoc misc/cronjobs/delete_patrons.pl"
- Note the absence of information about the potential conflict
between --not_borrowed_since and anonymization
- Apply this patch
- Re-run the perldoc command and make sure the note about
anonymization make sense
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We often get asked where something can be found in setting,
adding the hint that RealTimeHoldsQueue is a system preference
is hopefully helpful here.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The real time hold queue and the build_holds_queue.pl jobs are not 100% compatible in that we should not be running the cron if the real time queue is enabled, this could lead to double server work. It would be good to have a check in build_holds_queue for the RealTimeHoldsQueue syspref and not run the job if the preference is enabled.
There might be times when we'd want to force a run of this job without changing the syspref. To that end we would also want a flag for this job so that system administrators could force the job from the command line if required, overriding this limitation.
Test Plan:
1) Apply this patch
2) Try run misc/cronjobs/holds/build_holds_queue.pl with the -h/--help and -m/--man options
3) Disable RealTimeHoldsQueue
4) Run with no options, should succeed
5) Enable RealTimeHoldsQueue
6) Run with no options, should display a message and not rebuild the
holds queue
7) Run again with the -f/--force option, should succeed
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Like Bug 26832 added binmode UTF-8 to script misc/search_tools/export_elasticsearch_mappings.pl, this should be added to misc/cronjobs/runreport.pl.
Test plan :
1) Do not apply patch
2) Create a SQL report with :
SELECT 'accentué',barcode FROM items limit 3
3) Note the id of this report, for example 1
4) Run : misc/cronjobs/runreport.pl 1 --format csv | tee /tmp/without.csv
=> You see output with unknown character instead of é :
5) Run : file --mime-type /tmp/without.csv
=> You see : /tmp/without.csv: iso-8859-1
6) Apply patch
7) Run : misc/cronjobs/runreport.pl 1 --format csv | tee /tmp/with.csv
=> You see correct output with é
8) Run : file --mime-type /tmp/without.csv
=> You see : /tmp/without.csv: utf-8
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds background queue options to cleanup_database.pl to allow
for purging completed background jobs.
--bg-jobs DAYS Purge all finished background jobs this many days old. Defaults to 1 if no DAYS provided.
--bg-type TYPE What type of background job to purge. Defaults to "update_elastic_index" if omitted
Specifying "all" will purge all types. Repeatable.
To test:
1 - Enable elastic search in Koha
2 - perl misc/maintenance/touch_all_items.pl
3 - Generate an number of diffrent types of bg-jobs (eg batch_hold_cancel,
batch_biblio_record_deletion, batch_item_record_deletion)
4 - Check db and note there are a bunch of diffrent jobs
5 - Update to make them old
UPDATE background_jobs SET ended_on = '2022-10-01 00:00:00', status='finished'
6 - perl misc/cronjobs/cleanup_database.pl
7 - Note bg-jobs entry shows in help
8 - perl misc/cronjobs/cleanup_database.pl --bg-jobs 1 -v
9 - Note that elasticqueue would have been cleared
10 - perl misc/cronjobs/cleanup_database.pl --bg-jobs 1 -v --confirm
11 - Note that number of entries deleted is reported
12 - Attempt to clear other job types, including "all" eg
perl misc/cronjobs/cleanup_database.pl --bg-jobs 1 --bg-type batch_item_record_deletion -v --confirm
perl misc/cronjobs/cleanup_database.pl --bg-jobs 1 --bg-type all -v --confirm
13 - Confirm in staff interface that jobs are gone:
http://localhost:8081/cgi-bin/koha/admin/background_jobs.pl
(Uncheck 'Current jobs only')
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It would be nice to be able to combine several types in a single run,
but exclude others, without having to have multiple cron lines
Test Plan:
1) Apply this patch
2) Run process_message_queue.pl with a single -c parameter
3) Note behavior is unchanged
4) Run process_message_queue.pl with multiple -c parameters
5) Note all the codes specified are processed
6) Repeat 2-5 with -t for type limits
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Currenlty the output with -v from overdue_notices is a bit overwhelming and hard to parse
I do a few things here:
1 - Only show SQL if verbose > 1
2 - Add some separators to make it more readab;e
3 - Remove some redundant messages with branchcode and borrowernumber
To test:
1: perl misc/cronjobs/overdue_notices.pl -v
2: Notice you get a LOT of information all smushed together
3: Apply patch
4: perl misc/cronjobs/overdue_notices.pl -v
5: Less info, and easier to read
6: perl misc/cronjobs/overdue_notices.pl -v -v
7: All the info, but nicer to read
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
cleanup_database.pl cronjob has a typo in it's usage/help:
"preserve-logs" option should be "preserve-log" as it is everywhere
in the code.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This script had some oddities:
- There was a LEFT JOIN to subscription, but no error printed if no subscription
I changed this to a JOIN as there is a constraint, so this shoudl not happen
- Publisheddate was checked after the SQL, moved into query
- We checked for the next issue, and marked late only if that issue was already expected
This overruled grace period, which should be the mnarker for a serial being late
The grace period should be extended if you wish to wait for next issue
- If no next published date, we reported an error on the planneddate
- Script without confirm had no reporting
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Added command line ooption logging and completion logging where
cronlogaction was already imported. We should probably standardize all
cronjobs, but this is a start
One cron didn't log on confirm, likely we need to update all crons to log
if confirm, and possibly not log if running in test mode? Another bug as well
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch proposes a new standard for cronlogaction
We copy @ARGV into a space separated string, then pass this to
cronlogaction
At the end of the script we add a call with info "COMPLETED"
To test:
1 - Apply patch
2 - perl misc/cronjobs/advance_notices.pl -v -m 4 -n -c
3 - sudo koha-mysql kohadev
4 - SELECT * FROM action_logs WHERE interface="CRON";
5 - Note start and completion logged
6 - Note command line arguments included in info
If this looks good I will copy this pattern to the other cronjobs
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The overdue and pre-overdue cron scripts are not skipping the generation of phone notices. This causes many phone notices to be created that will always be left at 'pending' as the Talking Tech outbound script creates its own phone notices and puts them in the message queue.
Test Plan:
1) Enable Talking Tech
2) Enable predue and overdue notice phone transports for a patron
3) Generate overdues and predues, notice phone notices are generated
4) Apply the patch
5) Repeat steps 2-3
6) Note phone notices are not generated
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some libraries don't want to auto-cancel holds, but we should not remind
a patron about a hold which has expired.
To test:
1 - Place a hold for a patron
2 - Set it waiting
3 - Run the holds reminder script in the future
perl misc/cronjobs/holds/holds_reminder.pl -day 1 --date '2023-09-12' -v
4 - Note the holds would be reminded
5 - Set expirationdate for the hold less than today
UPDATE reserves SET expirationdate = DATE_SUB(CURDATE(), INTERVAL 1 DAY);
6 - Run the remidner cron again
7 - No holds trigger!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
