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>
This patch makes the script use an execution lock as provided by
Koha::Script. Previous attempt got too complex and contentious, and
given we have a simple way to achieve the same thing, I decided to
submit an alternative approach.
To test:
1. Apply this patch
2. Add the following content to misc/cronjobs/process_message_queue.pl
on line 83:
sleep 100;
3. Save the file
4. Have two terminals open
5. On the first one, run:
$ kshell
k$ misc/cronjobs/process_message_queue.pl
6. On the second one, run the same
=> SUCCESS: The second one dies telling it had to skip the run
7. Undo your changes:
$ git checkout misc/cronjobs/process_message_queue.pl
8. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Liz Rea <liz@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It's slightly debatable whether auto_too_soon is an error or not. I think
it leans far enough towards error that the other patch is correct. The change, however,
will affect notices and means we cannot count auto_too_soon anymore
This patch adds a new 'results' hash to the info - this includes a count per error
(including auto_renew i.e. success) allowing for notices to decide how to display the info.
To test:
1 - Add to Auto renew digest notice:
[% IF results %]
There were [% results.auto_too_soon %] items that were too soon.
[% END %]
2 - Check out some items to a patron that will be too soon
3 - Check out one that is not too soon and will renew
4 - Ensure patron has auto renew digest selected and that AutoRenewalNotices is set to follow patron preferences
5 - Run the auto renewals cron
6 - Confirm the notice for the patron displays 1 successful renewal, no failures, and a correct count of too_soon
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch prevents auto_too_soon errors being counted towards auto
renew errors.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch defaults to using "email" rather than "sms" notices
when AutoRenewalNotices is set to use the --send-notices cron switch
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Following bug 18532, one can set a patron's messaging prefs to deliver an auto-renew notice via SMS.
However, the auto_renewals cron only knows how to generate email notices. We should not allow the selection of non-functional transport types.
Test Plan:
1 - Set pref AutoRenewalNotices - 'according to patron messaging preferences'
2 - Set circ rule with:
Loan period: 5 days
No renewal before: 5
AutoRenewal: Yes
Renewals allowed: 5
3 - Set SMS Send driver to Email
4 - Find a patron and set them to receive auto renewal notices via SMS and no other transport
5 - Provide a proivder and sms number for the patron
6 - Checkout an item to the patron, set due date to yesterday
7 - Run auto renewals:
perl misc/cronjobs/automatic_renewals.pl -v --send-notices -c
8 - Item renewed, no message sent
9 - Check in item, checkout again due yesterday
10 - Apply patch
11 - Browse to Tools->notices and slips
12 - Edit AUTO_RENEWALS and AUTO_RENEWALS_DIGEST to copy email template to sms and add a title
13 - perl misc/cronjobs/automatic_renewals.pl -v --send-notices -c
14 - Item renewed, confirm patron has a notice in their account
15 - Check the digest option, check in item, checkout again as due, repeat cronjob and note digest notic
16 - sign off
https://bugs.koha-community.org/show_bug.cgi?id=30355
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes the script use the Koha::DateUtils tools instead.
To test:
1. Run:
$ kshell
k$ perl misc/cronjobs/batch_anonymise.pl --verbose --days 7
=> SUCCESS: You see (the date may vary):
Checkouts and holds before 2022-02-15 will be anonymised.
2. Apply this patch
3. Repeat 1
=> SUCCESS: Same output
4. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The Talking Tech outbound script currently just adds the
ReservesMaxPickUpDelay to the waiting date to calculate the
"expiration date", but it should use the actual hold expiration
date which may differ from this naive calculation based on
various system preference values.
Test Plan:
1) Create a holiday for tomorrow
2) Set ReservesMaxPickUpDelay to 5
3) Set "Days mode" to "Same week day"
4) Enable ExcludeHolidaysFromMaxPickUpDelay
5) Enable TalkingTechItivaPhoneNotification
6) Create a hold and fill the hold so it is waiting
7) Enable "Hold filled" phone notices for that patron
8) Create a 'phone' version of the HOLD notice
9) Run ./misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl --type RESERVE -w 0
10) Note the output has the expiration date ( 15th colume ) 5 days from now which is *not* the hold's expiration date
11) Apply this patch
12) Repeat the command from step 9
13) Note the expiration date column now matches the holds actual expiration date!
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
System preference 'CSVdelimiter' has a special case for tabulation.
Preference value contains string 'tabulation' but string '\t' must be used in CSV file.
This is OK in many places, for exemple Bug 17590.
This patch adds C4::Context->csv_delimiter to add a uniq metod dealing
with this behavior.
Also create Koha::Template::Plugin::Koha->CSVDelimiter for calls from
Toolkit Templates.
Test plan :
1) Set system preference 'CSVdelimiter' = 'tabs'.
2) Create CSV export in impacted pages
3) Check columns are separated by tabulation character and not string 'tabulation'
4) Check with another delimiter
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1. Have a report containing:
SELECT tomascohen@theke.io;
2. Have a members notice containing ¡ and other non-ASCII characters.
3. Run (changing the report number and notice code accordingly):
$ kshell
k$ perl misc/cronjobs/patron_emailer.pl --report 4 \
--notice BIRTHDAY --from tomascohen@theke.io --module members
=> FAIL: non-ASCII characters are broken
4. Apply this patch
5. Repeat 3
=> SUCCESS: Things print correctly!
6. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
