This highlights the issue mentioned in the last patch, reporting that
nothign will be done and exiting the script
To test:
1 - perl misc/cronjobs/longoverdue.pl -l 5=1 --library CPL
2 - Confirm script exits with warning that nothing has been done
Sponsored-by: MAIN Library Alliance
Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The test plan here is largely confirming that nothing has changed.
Using CircControl here has an existing problem - when set to 'PickupLibrary'
the check in this cron looks for items from the userenv branch - the cron doesn't
have a userenv branch, it is undef, so for any library limiting by branch and
with CircControl set to 'PickupLibrary' / 'the library you are logged in at' the cron will do nothing
Sponsored-by: MAIN Library Alliance
Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We sent a SIGKILL to the daemon which does not let it cleanup
Updating to SIGTERM (15) and handle the dbh disconnect gracefully in the
daemon.
Also handle SIGINT (ctrl+c) only because I think it can be useful (?)
Test plan:
prove t/db_dependent/www/search_utf8.t
=> Without this patch there are 3 warnings in the DB container log
db-1 | 2025-10-03 12:30:57 362 [Warning] Aborted connection 42 to db: 'koha_kohadev' user: 'koha_kohadev' host: '172.19.0.6' (Got an error reading communication packets)
=> With this patch applied there are none.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Generated using
`perl misc/devel/tidy.pl --perl`
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
See bug 41316 - the script uses the triggers of the issuing branch when sending
by patron library - we shouldn't change this here, but on the next bug
Signed-off-by: Ben Daeuber <bdaeuber@fargolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Ben Daeuber <bdaeuber@fargolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We are in a loop here:
foreach my $branchcode (@branches) {
branchcode must be defined or something has gone seriously wrong with PERL
Signed-off-by: Ben Daeuber <bdaeuber@fargolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a new variable $notice_branchcode and uses this when getting the patron's
homelibrary to ensure we don't change the branch we are using.
To test:
1 - At branch A - checkout three items, 1 day overdue to 3 patrons of the same category from different branches (not A)
2 - Set the system preference OverdueNoticeFrom to 'patron home library'
3 - Browse to More->Tools->Overdue notice/status triggers
4 - Set overdue triggers for default library and the category used above to:
Delay: 1
Letter: Overdue notice (ODUE)
5 - From the command line run the overdue notices:
perl misc/cronjobs/overdue_notices.pl --triggered --library CPL --test --nomail -v -v
6 - Note that we begin pass 1 with CPL and then use a different branch for passes 2 and 3
7 - Apply patch
8 - Repeat
9 - Confirm branch is consistent
10 - Run without branch param:
perl misc/cronjobs/overdue_notices.pl --triggered --library CPL --test --nomail -v -v
11 - Confirm branches are consistent
Signed-off-by: Ben Daeuber <bdaeuber@fargolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This follow-up updates runreport.pl to use the newer simplified
File::Transport API introduced by bug 40811, which provides:
- Automatic connection management (no explicit connect/disconnect)
- Simplified directory handling via options hash
- Cleaner, more maintainable code
The upload functionality now uses a single upload_file() call with
a path option instead of requiring separate connect() and
change_directory() calls.
Also fixes minor inconsistencies in error messages (missing colons
and escaped quotes).
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds S/FTP upload support to runreport.pl by adding additional command-line flags that will, when utilised, deposit a report onto the configured S/FTP Server.
== TO TEST ==
a) Goto /cgi-bin/koha/admin/file_transports.pl?op=add_form
b) Configure an S/FTP Server
*) If one needs an S/FTP Server to utilise, contact me directly
c) Configure an SQL report under Reports > Create from SQL
*) If you're stuck, you can use `SELECT * FROM items` to select every item in k.t.d to report on
== APPLY PATCH ==
d) Run `./misc/cronjobs/runreport.pl` without arguments
*) Notice `--sftp-dest-id` and `--filename`
*) `--sftp-dest-id` specifies the ID of the configured server to use, which can be garnered from the URL when editing the server (look for the file_transport_id parameter)
*) `--filename` optionally specifies what the file should be called when uploaded, and can be customised with bash variables if necessary
e) Run `./misc/cronjons/runreport.pl --sftp-dest-id 1 1`
*) Notice the script outputs nothing, indicating success
*) On your S/FTP server, notice a report now named report(id)-(date).csv
*) Notice that the outputted file contains a CSV-formatted report
f) Run `./misc/cronjobs/runreport.pl --format html --sftp-dest-id 1 1`
*) Notice the script outputs nothing, indicating success
*) On your S/FTP server, notice a report now named report(id)-(date).html
*) Notice that the outputted file contains an HTML-formatted report
g) Run `./misc/cronjons/runreport.pl --filename custom.csv --sftp-dest-id 1 1`
*) Notice the script outputs nothing, indicating success
*) On your S/FTP server, notice a report now named custom.csv
*) Notice that the outputted file contains a CSV-formatted report
h) Run `./misc/cronjons/runreport.pl --format html --filename custom.somehtml --sftp-dest-id 1 1`
*) Notice the script outputs nothing, indicating success
*) On your S/FTP server, notice a report now named custom.somehtml
*) Notice that the outputted file contains an HTML-formatted report
== SIGN OFF ==
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
test plan:
1. Export a record with an item from the staff interface as MARCXML (Save > MARCXML).
2. Edit the file and remove the 952$a (home library) and 952$b (current library).
3. Delete the item and record in the staff interface.
4. Import the exported record and item from the MARCXML file:
- Cataloging > Import > Stage for import
. Settings > Format: MARCXML
- Stage for import
- View batch link on the job details page (assuming successfully staged)
. New record framework: change to Books, Booklets, Workbooks
5. Turn on the browser developer tools and view the console.
6. Access the details page for the new record.
7. Note that you get:
- A "Processing" dialog box on screen
- A browser pop-up window/dialog box with:
Something went wrong when loading the table.
500: Internal server error
- Click OK
- The console shows:
. Failed to load resource: the server responded with a status of 500 (Internal Server Error)
. Got 500 (Internal Server Error)
. DataTables warning: table id=holdings_table - Ajax error. For more information about this error, please see https://datatables.net/tn/7
8. Run misc/maintenance/search_for_data_inconsistencies.pl, you get these result (the itemnumber may be different):
== Not defined items.homebranch and/or items.holdingbranch ==
* Item with itemnumber=973 does not have home and holding library defined
=> Edit these items and set valid homebranch and/or holdingbranch
(↑↑ don't do it, it's part of the message content)
9. Apply the patch.
10. Restart everything.
11. Refresh the details screen for the imported record.
12. You now get the same as step 7, but with added "Have a look at the "Audit" button in the toolbar" text in the browser pop-up dialog box:
- A "Processing" dialog box on screen
- A browser pop-up window/dialog box with:
Something went wrong when loading the table.
500: Internal server error
Have a look at the "Audit" button in the toolbar
- Click OK
- The console shows:
. GET http[URL for the record....] 500 (Internal Server Error)
. Got 500 (Internal Server Error)
. DataTables warning: table id=holdings_table - Ajax error. For more information about this error, please see https://datatables.net/tn/7
13. Click on the Audit button.
14. You get a yellow box at the top of the record with:
Errors found
Item with itemnumber=973 does not have home and holding library defined
(Note that there is still the "Processing" dialog box, you can edit the item by select the "Items" option in the sidebar menu and then edit the item details - the home and current library files will be auto-populated with the current library, Centerville with KTD)
15. Repeat step 8, you get the same results.
16. The tests pass: prove t/db_dependent/Koha/Database/DataInconsistency.t
17. Check the details page for another record that doesn't have any data issues - note the 'Audit' toolbar item, and if clicked should show a blue box at the top of the record with "No data inconsistency found."
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This updates the documentation for the
misc/bin/connexion_import_daemon.pl --help option.
Test plan:
1. Run ./misc/bin/connexion_import_daemon.pl --help
2. Read the output and check for errors, whether grammatical,
spelling, or factual.
Sponsored-by: Reformational Study Centre <www.refstudycentre.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This changes "Koha administration" to "Administration" on the
staff interface home page and the administration module home page.
Everywhere else in the staff interface, such as browser page titles
and breadcrumbs, administration is used.
This improves consistency, and is how it is commonly referred to.
It also change some other occurences in the code base, such
as code comments.
Test plan:
1. Note the inconsistencies in how we name and refer to the
administration module:
1.1 Staff interface home page: Koha administration
1.2 Administration module home page: Koha administration, but note
that the breadcrumb and browser page title is "Administration".
1.3 Breadcrumbs and browser page titles for any of the administration
areas are just "Administration".
1.4 More > Administration.
2. Apply the patch.
3. Note that on the staff interface home page and the administration
home page are now labelled "Administration".
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
After bug 35659 that added the OAI harvester to Koha the -d switch
for deleting authorities before importing with bulkmarcimport.pl
was broken and resulted in a FK error.
Switching from truncate to DELETE FROM like we already did for items,
biblio etc. fixes the issue.
To test:
- Make sure you have some authorities in your database
- Export some into a file for importing
- Run bulkmarcimport -a -d --file <filename>
- Verify you get the a DB FK constraint error.
- Apply patch
- Repeat steps, verify the script now works as expected again
* Existing authorities are deleted
* File is imported
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
So it is done before the other use statements.
Also uniformize the pattern, must now be:
```
use Modern::Perl;
use base 'Exporter';
BEGIN {
our @EXPORT_OK = qw(subroutine list);
}
```
Rebased-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Bug38936 exported redirect_if_opac_suppressed
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch introduces a new unique restriction type 'FINES' specifically
for the debar_patrons_with_fines.pl script to prevent duplicate
restrictions on repeated runs.
The original fix used 'SUSPENSION' but this conflicted with the
fine-in-days feature which uses SUSPENSION for time-limited restrictions
when overdue items are returned. Running the script would overwrite
those time-limited restrictions with indefinite ones.
Changes:
- Add new 'FINES' system restriction type to patron_restriction_types.yml
for new installations
- Create database update to add 'FINES' type to existing installations
- Update debar_patrons_with_fines.pl to use 'FINES' instead of 'SUSPENSION'
- Update AddUniqueDebarment and DelUniqueDebarment POD documentation
This keeps SUSPENSION exclusively for the fine-in-days feature while
preventing duplicate restrictions from the fines script.
Test plan:
1. Run database update
2. Verify new FINES restriction type exists in restriction_types table
3. Run debar_patrons_with_fines.pl multiple times
4. Confirm only one FINES restriction per patron (no duplicates)
5. Verify SUSPENSION restrictions from fine-in-days are not affected
6. Run tests: prove t/db_dependent/Patron/Borrower_Debarments.t
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The cronjob debar_patrons_with_fines.pl is meant to add a restriction based on a fines threshold.
The problem is that the script adds a MANUAL restriction, which makes no sense. MANUAL restrictions are meant to be manually created, never automatic as this script does.
In addition, they are repeatable, not unique. Every time this script runs, it will add an additional restriction.
There is already a restriction type meant for this type of use case: SUSPENSION
We should change this script to create SUSPENSION restrictions instead of MANUAL restrictions.
In summary, this script should use the unique restriction type SUSPENSION to prevent multiple additional restrictions from being created on each run.
Test Plan:
1) Set up a patron with fines
2) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message"
3) Note the restriction is created
4) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message" again
5) Note another restriction is created
6) Delete the restrictions
7) Apply this patch
8) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message"
9) Note the restriction is created
10) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message" again
11) Note another restriction is *not* created!
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This enhancement will amend the automatic_renewals.pl script to only print a warning about the EnhancedMessagingPreferences system preference being disabled if the script was run with verbose.
To test:
1. Disable EnhancedMessagingPreferences
2. Run misc/cronjobs/automatic_renewals.pl
3. Notice the warning is printed
4. Apply the patch and restart services
5. Run misc/cronjobs/automatic_renewals.pl and notice the warning is not printed
6. Run misc/cronjobs/automatic_renewals.pl --verbose and notice the warning is printed
7. Enable EnhancedMessagingPreferences
8. Run misc/cronjobs/automatic_renewals.pl and notice the warning is not printed
Sponsored-by: Catalyst IT
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When --filename contains a path (e.g., /tmp/records.mrc), the script
was uploading to the remote server with the full path, creating
unwanted directory structures (e.g., uploads/tmp/records.mrc).
This patch uses File::Basename::fileparse() to extract just the
filename portion for the remote upload, while still using the full
path for local file operations.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Enhance the export_records.pl script with better error handling
and connection lifecycle management:
1. Connection Management:
- Always call disconnect() after file transport operations
- Ensure connections are cleaned up even on errors
2. Error Handling:
- Replace unusual die+pod2usage with clear error messages
- Add file existence validation before upload attempts
- Provide detailed error messages with context
- Consistent error message formatting
3. User Experience:
- Add validation for --delete_local_after_run without --destination_server_id
- Provide informative success messages to STDERR
- Better error messages with specific failure reasons
4. Robustness:
- Check if output file was created before upload
- Check if file exists before attempting deletion
- Graceful handling of missing upload directories
These improvements make the script more reliable and user-friendly
while maintaining all existing functionality.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This follow-up patch updates the terminology in export_records.pl to use
generic 'file transport' language instead of specific 'FTP/SFTP' references,
aligning with the recent renaming of the underlying classes to File::Transports.
Changes:
- Replace $sftp_server variable with $file_transport for clarity
- Update error messages to use 'file transport server' terminology
- Fix incorrect error message for report_id validation
- Update POD documentation to reference 'file transport servers'
- Maintain consistency with the renamed admin interface and API
This ensures the script terminology matches the current class structure
and admin interface naming conventions.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds two new flags to the export_records.pl script.
* --destination_server_id=ID
This flag will, when passed, upload the file generated by this script to
the destination server, as configured in the FTP/SFTP Servers settings.
* --delete_local_after_run
This flag will, when passed, cause the script to unlink (delete) the
generated marc or CSV file found on the local disk. This is useful for folk
who want to upload the file, but not necessarily keep a local copy, filling
up the server's storage medium
TO TEST:
a) APPLY PATCH, reset_all
b) Create valid FTP/SFTP Server in Koha settings, ensuring that the server
you create is valid and passes testing
c) Run ./misc/export_records.pl with no agruments
1) Notice how koha.mrc file is generated
d) Run ./misc/export_records.pl --destination_server_id=1
1) Notice how koha.mrc file is generated
2) On your FTP/SFTP Server, notice how koha.mrc is now present in the
upload directory
e) Run ./misc/export_records.pl --delete_local_after_run
1) Notice how koha.mrc file is NOT generated locally
f) Run ./misc/export_records.pl --destination_server_id=1 --delete_local_after_run
1) Notice how koha.mrc file is NOT generated locally
2) On your FTP/SFTP Server, notice how koha.mrc is still present in the
upload directory AND the file age is fresh
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The singular form is wrong and only exists in textual context.
This is a result of git grep | xargs sed.
Test plan:
Read the patch.
git grep BorrowerLog
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Aleisha Amohia <aleisha@catalyst.net.nz>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The command currently logs when deleting indexes and indexing records, it would be helpful
to have a log when resetting the mappings, and to log which mapping file has been used.
To test:
1 - perl misc/search_tools/rebuild_elasticsearch.pl -r
2 - No log of reset
3 - Apply patch
4 - perl misc/search_tools/rebuild_elasticsearch.pl -r
5 - Note reset is logged
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This adds a command-line utility script that allows administrators to reset
a patron's two-factor authentication settings when they lose access to their
authenticator device.
The script uses the new Koha::Patron methods and provides:
* Parameter validation (mutually exclusive userid/cardnumber/patron_id)
* User-friendly error messages and feedback
* Verification that patron has 2FA enabled before attempting reset
To test:
1. Enable TwoFactorAuthentication system preference
2. Set up 2FA for a test patron
3. Run:
$ ktd --shell
k$ perl misc/admin/reset_2fa.pl --userid <userid>
=> SUCCESS: Script resets 2FA and shows confirmation message
4. Verify patron can log in with password only
5. Test error cases:
- No parameters: shows usage message
- Multiple parameters: shows mutual exclusivity error
- Non-existent user: shows user not found error
- User without 2FA: shows informational message
=> SUCCESS: All scenarios work as expected
6. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
With the move to the latest ES versions we got rid of 'data' type - we need to use '_doc'
To test:
1 - Delete a record from the DB directly
DELETE FROM biblio WHERE biblionumber=45;
2 - perl misc/maintenance/compare_es_to_db.pl
3 - Try the curl command - it doesn't work
4 - Apply this patch
5 - perl misc/maintenance/compare_es_to_db.pl
6 - Try the curl command - it now fetches the record
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds --biblios and --authorities options to the script to allow
checking only a single index
To test:
0 - Apply patch
1 - perl misc/maintenance/compare_es_to_db.pl
2 - biblios and authorities are checked
3 - perl misc/maintenance/compare_es_to_db.pl -b
4 - Only biblios are checked
5 - perl misc/maintenance/compare_es_to_db.pl -a
6 - Only authorities are checked
7 - perl misc/maintenance/compare_es_to_db.pl -a -b
8 - Both indexes are checked
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Cronjob cleanup_database.pl usage is wrong :
Usage: $0 [-h|--help] [--confirm] (...) [--bg-days DAYS [--bg-type TYPE] ]
Those args has been renamed jobs-days and jobs-type.
Also some args are missing.
There are too many args, I propose to remove them from there, one need to read the full help.
Test plan:
Run command line `misc/cronjobs/cleanup_database.pl -h`
You see first line:
Usage: misc/cronjobs/cleanup_database.pl
-h --help prints this help message, and exits, ignoring all
...
Signed-off-by: Anke Bruns <anke.bruns@gwdg.de>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If the holds reminder cronjob would send a reminder on a holiday,when holidays are taken into account, it also will send it on the subsequent holidays and the first open day.
This bugfix adds a check to the cron when --holidays is set to skip sending the notices for that library if today is a holiday.
To Test:
Before applying:
1. Create a hold for a patron (I used patron 23529000035676 and 39999000000252)
2. Ensure your patron has an email address set and the hold reminder email selected.
3. Set the hold to waiting by checking it and confirming the hold.
4. In Tools->Calendar add a holiday to yesterday and a seperate holiday to today.
5. On the command line (the date should be set to 5 days ago for my commands to work and any dates adjusted accordingly)
koha-mysql kohadev
update reserves set waitingdate="2025-09-25"
exit
perl misc/cronjobs/holds/holds_reminder.pl -days 3 -t -v -holidays --date 2025-09-29
6. Observe that 1 notice would have sent to your patron
7. On the command line
perl misc/cronjobs/holds/holds_reminder.pl -days 3 -t -v -holidays
8. Observe that 1 notice would have sent to your patron
9. On the command line
perl misc/cronjobs/holds/holds_reminder.pl -days 3 -t -v -holidays --date 2025-10-01
10. Observe that 1 notice would have sent to your patron
11. Apply patches
12. Repeat the last command from step 5 and step 7
13. Observe that no notice should be sent for your patron
14. Repeat step 7
15. Observe that a notice should be sent for your patron.
16. Run
perl misc/cronjobs/holds/holds_reminder.pl -days 5 -t -v
17. Confirm the notice should be sent for your patron
18. Sign off
Signed-off-by: Katie Bliss <KEBliss@dmpl.org>
Bug 35700: (QA follow-up) fix POD and $today
This patch replaces the inncorrectly removed POD note and replaces $today with the more correct $date_to_run for checking if we should be skipping sending the message on the day.
Amended-by: Jonathan Druart
Squashed and adjusted commit title
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Executing marc_ordering_process.pl will fail to run with the following errors:
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 21: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 23: marc_ordering_process.pl: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 25: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: --confirm]: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: --verbose]: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: ./marc_ordering_process.pl: No such file or directory
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 29: or,: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 31: 0: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 33: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 35: This: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 36: If: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 38: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 40: =over: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 42: syntax error near unexpected token `newline'
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 42: `=item B<-v|--verbose>'
This is due to an inadvertent newline before the shebang of the script.
Test Plan:
1) Run ./misc/cronjobs/marc_ordering_process.pl
2) Note the error
3) Apply this patch
4) Run ./misc/cronjobs/marc_ordering_process.pl
5) No error!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The es_indexer_daemon.pl was missing handling for the case where
Koha::BackgroundJob->connect() returns undef without throwing
an exception (which happens when connection fails silently).
This adds the missing warning for that case, matching the behavior
in background_jobs_worker.pl.
Test plan:
1. Set JobsNotificationMethod to 'STOMP'
2. Configure invalid STOMP settings that cause connect() to return undef
3. Run es_indexer_daemon.pl - should show connection warning
4. Verify jobs are still processed via database polling
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The background job workers are showing STOMP/RabbitMQ connection error
warnings even when the JobsNotificationMethod system preference was set
to 'polling', which doesn't require a message broker connection.
This patch adds checks for the JobsNotificationMethod preference before
displaying connection warnings, so warnings only appear when STOMP is
actually expected to be available.
Changes:
- misc/workers/background_jobs_worker.pl: Check syspref before warning
- misc/workers/es_indexer_daemon.pl: Check syspref before warning
Test plan:
1. Set JobsNotificationMethod to 'polling'
2. Run background_jobs_worker.pl - should not show STOMP warnings
3. Run es_indexer_daemon.pl - should not show STOMP warnings
4. Set JobsNotificationMethod to 'STOMP' without RabbitMQ running
5. Run workers - should show appropriate STOMP connection warnings
6. Sign off :-D
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This change checks for HTTP(S) URLs and skips the shell when using
system() so that shell metacharacters aren't interpreted.
Test plan:
0. Apply the patch
1. Insert the following into the Babeltheque_url_update system preference:
$(whoami > /tmp/rce.log)
2. koha-shell kohadev
3. perl misc/cronjobs/social_data/update_social_data.pl
4. Note the script says the following:
$(whoami > /tmp/rce.log) is not a HTTP URL. Aborting.
5. Note also that /tmp/rce.log is not created
6. Change Babeltheque_url_update syspref to something like the following:
http://localhost:8080
7. perl misc/cronjobs/social_data/update_social_data.pl
8. Note that the wget succeeds but the bunzip2 fails (as expected) since
we haven't fetched a bzipped file
9. Try to create a payload that passes the HTTP URL test with shell
metacharacters and note that they're not interpetted and instead
just used as part of a URL string.
Signed-off-by: Jake Deery <jake.deery@openfifth.co.uk>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch fixes an identified RCE in the update_social_data.pl
social_data, which when executed, allows an attacker to run arbitrary
code on the system's shell.
TO TEST:
a) In the Babeltheque_url_update syspref, wrap any bash in $(), and then
run the update_social_data.pl script.
*) For example, $(whoami >
/tmp/rce.log) will output to a file the username the perl script is
running as.
APPLY PATCH
b) Run the update_social_data.pl script again. The string is now
meta-escaped, and the RCE no longer works.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Since this patch updates the script to use Koha::Items->search instead of a direct database query
--where options that refer to the items table will be broken and result in an error like:
execute failed: Unknown column 'items.withdrawn' in 'where clause'
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a new option to the delete_items cronjob
When --del_bibs is set, bib records will be deleted
if the last item is deleted.
The following plan assumes default ktd data.
To test:
1. Apply patch
2. Check the holdings for bib #115 and see 3 items
http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=115
2. Run the cron with the following flags
perl ./misc/cronjobs/delete_items.pl --where "biblionumber=115 and homebranch ='MPL'" --verbose --del_bibs --commit
3. Notice in the output the count of current items on the bib record:
Where statement: where biblionumber=115 and homebranch='MPL'
Deleting empty bib records!
Deleting item '237' (of 3)
Deleting item '238' (of 2)
4. Confirm the two Midway items were deleted from bib #115, and the bib still exists with one item
4. Run the cron again but change the the --where flag to delete all the items from bib #115
perl ./misc/cronjobs/delete_items.pl --where "biblionumber=115" --verbose --del_bibs --commit
5. Notice in the output the bib is deleted after the last item is deleted
Where statement: where biblionumber=115
Deleting empty bib records!
Deleting item '239' (of 1)
Last item deleted - deleting bib '115'
8. Confirm the bib #115 was deleted
9. Add some more items and test with some other --where parameters
10. Test with and without --commit and --del_bibs, test the --help flag
Sponsored-by: CLAMS
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
I have added the options --include and --exclude to the install_plugins.pl script. When running the script, you can now specify which plugins you want to install (--include) and which ones you do not want to install (--exclude).
--include installs only the plugins from the specified classes.
--exclude installs all plugins except those from the specified classes.
It's possible to specify the package to install a specific plugin.
--include and --exclude cannot be used simultaneously.
Usage example:
./misc/devel/install_plugins --include <package::pluginClass> --include <anotherPluginClass>"
TEST PLAN
1) Apply the patch
2) Add at least three plugins to the plugin directory ([Koha]/plugins/Koha/Plugin/)
3) Empty the "plugin_data" and "plugin_methods" tables (SQL command: "delete from plugin_data; delete from plugin_methods;")
4) In a terminal, execute this command "./misc/devel/install_plugins.pl --include <package::pluginClass> --include <anotherPluginClass>" (Replace <package::pluginClass> and <anotherPluginClass> with the class and package of your plugins)
5) In your Koha intranet, go to "Koha administration > Manage plugins"
6) Verify that only the specified plugins are installed
7) Repeat step 3
8) In a terminal, execute this command from your Koha project"./misc/devel/install_plugins.pl --exclude <package::pluginClass> --exclude <anotherPluginClass>"
9) Verify that all plugins except the specified ones are installed
10) Run the tests from the Plugins.t file ([Koha]/t/db_dependent/Koha/Plugins/Plugins.t)
11) Ensure that all tests are successful
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Hammat Wele <hammat.wele@inlibro.com>
Signed-off-by: Amaury GAU <amaurygau@gmail.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
From https://css-tricks.com/snippets/css/make-pre-text-wrap/
/* Browser specific (not valid) styles to make preformatted text wrap */
pre {
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+ */
}
... I think it's now safe to remove the backward compatibility versions and simply keep pre-wrap.
Test plan (from bug 921)0:
* place a hold on a title with a very very long title or author
* mark it as "waiting for pickup" by doing a checkin
* go to command line interface, and run
* misc/cronjobs/gather_print_notices.pl /tmp
* misc/cronjobs/printoverdues.sh /tmp
* if your title/author is long enough, it's splitted on 2 lines
with this patch (it is not before this patch)
It will also remove the warnings from t/db_dependent/Patron/Borrower_Discharge.t
WARNING: Ignored `white-space: -moz-pre-wrap` at 6:14, invalid value.
WARNING: Ignored `white-space: -o-pre-wrap` at 7:14, invalid value.
WARNING: Ignored `word-wrap: break-work` at 8:14, invalid value.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
With this patch we adjust what's needed to make misc/devel/tidy.pl run
identically as before
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch introduces a new Koha::Devel namespace. It clearly shows
that its purpose is for development and will not contain any business
logic.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
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: Lucas Gass <lucas@bywatersolutions.com>
For creating this patch I looked at all parameters defined in the
handler mapping, removed duplicated ones and tracked down which ones
really were parameters in `GetOptions`. This included tracking down
variables that were later assigned other values and things like that.
The mapping is used to display the right parameter name if missing a
mandatory one.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Bug 31143 created a script in cronjob and then moved it to maintenance. However, it is still referred as in cronjob in help strings. This patch updates the hint.
No test needed I guess. Only changing a string
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>