This patch adds a new option to define the providers in cronjob erm_run_harvester.pl
that are used to run the SUSHI harvesting for COUNTER Reports in the ERM module.
Use parameter --provider-id or -p
The parameter provider_id is repeatable.
If the parameter for provider_id is not used all active providers will be harvested (as before).
The script will check if these providers are active (as before).
Script to run on ktd: perl misc/cronjobs/erm_run_harvester.pl --begin-date 2025-09-01 --end-date 2025-09-30
To test:
- Run the script and make sure that all active providers are harvested.
- Apply patch.
- Run the script with only one provider-id.
- Run the script with two provider-ids by using -p 1 -p 2
- Run the script without the parameter.
- Make sure that in all cases only active providers are harvested.
- Sign off :-).
Sponsored-by: Karlsruhe Institute of Technology (KIT)
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 43d32f77d6)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Test plan (for --cards arguments) :
1. Initial Setup:
a) Go to Tools > Patron card creator > New > Card batch
b) Create two different batches (Batch 1 and Batch 2) using the 'Add by borrowernumber(s):' option.
If using **KTD** you can use the following borrowernumbers for both batches:
15
29
47
else you will need to create your own patrons and enter their borrowernumber.
c) In your terminal, set the timestamps manually:
--OPTION A (KTD users):
ktd --shell
koha-mysql kohadev
--OPTION B:
Access your database
Then:
UPDATE creator_batches SET timestamp = DATE_SUB(NOW(), INTERVAL 30 DAY) WHERE batch_id = '1';
UPDATE creator_batches SET timestamp = DATE_SUB(NOW(), INTERVAL 5 DAY) WHERE batch_id = '2';
Note: your batch_id may differ.
2. Before Applying the Patch:
a) Run the following cleanup script:
./misc/cronjobs/cleanup_database.pl --cards 15 --confirm --verbose
b) Error in console output
c) Nothing is deleted even though one batch was older than 15 days
SELECT * FROM creator_batches;
3. Apply The Patch
4. After Applying The Patch:
a) Redo step 1 (Initial Setup).
b) Run again the following cleanup script:
./misc/cronjobs/cleanup_database.pl --cards 15 --confirm --verbose
c) Check that the console output says: "Purging ... more than 15 days ago"
d) Batch 1 is deleted, but Batch 2 (5 days old) is STILL PRESENT. Success!
SELECT * FROM creator_batches;
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 0c2ef0e6b4)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Test plan :
1. Initial Setup:
a) Go to Cataloging > Label creator > New > Label batch
b) Create two different batches (Batch 1 and Batch 2) using the 'Add by barcodes or itemnumbers' option.
If using **KTD** you can use those barcodes for the two batches:
39999000010114
39999000010138
39999000010152
else you will need to create your own records with items and enter their barcodes.
c) In your terminal (in a ktd --shell), set the timestamps manually:
--OPTION A (KTD users):
ktd --shell
koha-mysql kohadev
--OPTION B:
Access your database
Then:
UPDATE creator_batches SET timestamp = DATE_SUB(NOW(), INTERVAL 30 DAY) WHERE batch_id = '1';
UPDATE creator_batches SET timestamp = DATE_SUB(NOW(), INTERVAL 5 DAY) WHERE batch_id = '2';
Note: your batch_id may differ.
2. Before Applying the Patch:
a) Run the following cleanup script:
./misc/cronjobs/cleanup_database.pl --labels 15 --confirm --verbose
b) Check that the console output says: "Purging ... more than 1 days ago"
c) Check database and notice that it is now empty, even though one set was less than 15 days old.
SELECT * FROM creator_batches;
3. Apply The Patch
4. After Applying The Patch:
a) Redo step 1 (Initial Setup).
b) Run again the following cleanup script:
./misc/cronjobs/cleanup_database.pl --labels 15 --confirm --verbose
c) Check that the console output says: "Purging ... more than 15 days ago"
d) Batch 1 is deleted, but Batch 2 (5 days old) is STILL PRESENT. Success!
SELECT * FROM creator_batches;
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 9e05ca0e19)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 5fed11a14c)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
HTML1 is gone. Almost...
The previous rule said that we could not have TT tags within HTML tags
because it caused problems with the translation.
It was incorrect.
Bug 38720 removed that rule, and stated that the only problematic use
was a IF with ">".
It was also incorrect.
This one bug states that we cannot have TT tags to construct HTML tags
IF one of the attribute contains a translatable string.
The list of translatable attributes are listed in tmpl_process3.pl.
This patch restores xt/tt_valid.t (and move it to xt/author) and adjust
slightly the test to take into account this last statement.
Test plan:
0. Apply only this first patch
1. Run xt/author/tt_valid.t
=> It fails on mana-subscription-search-result.inc
2. Update po for your prefered language
=> The string "This resource has been reported more than" is not in the
po files
3. Apply the second patch, repeat 1 and 2
=> It still fails: adding a space between the TT tag and the attribute is not enough here
=> The string is picked now! but... install the template and open the
translated version =>
4. Apply the third patch, repeat 1 and 2
=> The tests pass!
=> The string is still picked, install => The template looks good!
Now if you are familiar with Mana you can try to see the translated
string on the UI
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 952933c31e)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
xgettext.pl tries to produce output to STDOUT by default, but fails
because of an error in the code. It should go to the actual STDOUT
instead of a file named '&STDOUT'.
Test plan:
1. Run xgettext.pl:
echo koha-tmpl/opac-tmpl/bootstrap/en/includes/serial-status.inc > transfiles
./misc/translator/xgettext.pl -vaf transfiles
2. Observe no standard output, and the existence of a file
called `&STDOUT`. Output to the screen is:
echo koha-tmpl/opac-tmpl/bootstrap/en/includes/serial-status.inc > transfiles
kohadev-koha@kohadevbox:koha(main)$ ./misc/translator/xgettext.pl -vaf transfiles
./misc/translator/xgettext.pl: Outputting to STDOUT...
./misc/translator/xgettext.pl: Opening input file list "transfiles"
./misc/translator/xgettext.pl: Processing file "./koha-tmpl/opac-tmpl/bootstrap/en/includes/serial-status.inc"
3. Apply the patch.
4. Run again.
5. Observe that information is output to the screen (see example of
outpunt in the bug comment).
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 0bcf87df38)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
If PatronSelfRegistration we should ignore (i.e. do nothing) if
--del-exp-selfreg is passed to cleanup_database.pl
It prevents the script to warn that the pref is not set.
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@openfifth.co.uk>
(cherry picked from commit d331c7aba8)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Currently the patron homelibrary option for OverdueNoticeFrom will select overdues for a branches triggers
based on the issuing branch
The other two options select the trigger/overdues based on the selection
This patch alters the selection of overdues to match only for the patrons branch
To test:
1 - Apply 41315 and follow the plan there
2 - Apply this bug and run the overdues script, assuming CPL is branch A:
perl misc/cronjobs/overdue_notices.pl --triggered --library CPL --test --nomail -v -v
3 - No overdues should be triggered
4 - Run the script for one of the patrons home libraries, in my case MPL
perl misc/cronjobs/overdue_notices.pl --triggered --library MPL --test --nomail -v -v
5 - Note only overdues for patrons from that branch are triggered
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>
(cherry picked from commit 036d92e654)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Koha is built to prevent sending duplicate notices. Notices with static language ( e.g. "You have one or more holds ready to pick up" ) will easily trigger this filter.
RestrictPatronsWithFailedNotices should ignore these notices because they do not indicate any problem with contacting the patron.
Test Plan:
1) Enable RestrictPatronsWithFailedNotices
2) Enqueue to identical notices for a patron
3) Run process message queue to send one and fail the other as a
duplicate ( alternately, just modify them in the database )
4) Run restrict_patrons_with_failed_notices.pl
5) Note the restriction
6) Remove the restriction
7) Apply this patch
8) Run restrict_patrons_with_failed_notices.pl
9) Note that no restriction was created!
Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 5779eec49b)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Interestingly this script already had a $surname variable, just never accepted a parameter for it.
This enhancement enables the user to supply a surname parameter when creating a superlibrarian user via the commandline create_superlibrarian.pl script. Koha patrons MUST have a name, so if no surname is provided, the userid will be used for the surname instead.
To test:
1. Apply the patch and restart services
2. Attempt to create a superlibrarian with no surname provided.
In KTD: misc/devel/create_superlibrarian.pl --userid test --cardnumber test --password XXXX --branchcode CPL --categorycode S
3. Search for your patron in Koha. Confirm the surname was automatically set to the userid 'test'
4. Attempt to create a superlibrarian, this time provide a surname that is different from the userid so easy to tell apart.
In KTD: misc/devel/create_superlibrarian.pl --userid test1 --cardnumber test1 --password XXXX --branchcode CPL --categorycode S --surname testsurname
5. Search for your patron in Koha. Confirm the surname was set correctly using the given surname.
Sponsored-by: Catalyst IT
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit c72fc81b76)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
This patch additionally fetches the reply to address for advance notices
To test:
1 - Have some issues that will be due soon for a patron(s)
Checkout with the due date set to tomorrow
2 - Verify the patron(s) have an email defined, verify the issuing branch has a reply to set
3 - Verify the patron(s) have messaging preference set to receive Advance notices by email 1 day in advance
4 - perl misc/cronjobs/advance_notices.pl -v -c
5 - Check the message queue
SELECT * FROM message_queue WHERE borrowernumber={##}
6 - Note no rpely to is set
7 - Apply patch
8 - perl misc/cronjobs/advance_notices.pl -v -c
9 - Check the message queue
10 - Confirm newer message has the reply to populated
11 - Ensure the issued item has a different homebranch with a reply to address se
12 - perl misc/cronjobs/advance_notices.pl -v -c --frombranch item-homebranch
13 - Confirm message has correct reply to
14 - Set patron to want digest in messaging preferences
15 - Generate notices
16 - Confirm digets has the right reply to
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tidied inline
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit d7028939da)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Thats quite old :)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit b8742964db)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
When using bulkmarcimport with the -d switch should not only delete
biblio, biblioitems and items, but also biblio_metadata.
I haven't checked if a FK takes care of the data, but if it does,
we should still also reset the AUTO_INCREMENT:...
Test plan:
==========
1. Check (and notice) the number of records in the biblio (bCount) and
biblio_metadata (bmCount) tables. Check the AUTO_INCREMENT value
for these tables (bAI, bmAI).
2. Import bibliographic records with delete, turn off foreign key checks
and non-existent filename:
misc/migration_tools/bulkmarcimport.pl -b -d -fk -file=non-exist-file
==> "Could not open..." is OK, file doesn't exist.
3. Repeat p. 1 and compare with previously noticed:
bCount => 0 (OK)
bmCount => unchanged (NOT OK)
bAI => 1 (OK)
bmAI => unchanged (NOT OK)
4. Apply the patch.
5. Repeat p. 2-3:
bCount => 0 (OK)
bmCount => 0 (changed, OK)
bAI => 1 (OK)
bmAI => 1 (changed, OK)
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Janusz Kaczmarek <januszop@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 8ec1b421bf)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 47d88a6429)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
This patch prevents us from passing the same record twice into the choose subs
to avoid a situation where the original record is not chosen as the one to keep
and we try to merge/delete the same record twice
To test:
1 - Run the script on a test system that you can reset
perl misc/maintenance/dedup_authorities.pl -v -v --confirm -a="PERSO_NAME"
2 - Note duplication of entries in the output like:
Merging 1660,1662 into 1660.
Updated 0 biblios
Deleting 1662
Merge done.
3 - Note how many records are merged
4 - Run again to confirm nothing is merged, i.e. the script removed the dupes
5 - Reset your DB
6 - Apply patch
7 - Run the script again
8 - Note entries no longer have duplicated ids:
Merging 1662 into 1660.
9 - Note the same number of records are merged
10 - Run again and confirm nothing is merged
11 - Sign off!
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>
(cherry picked from commit 7a5fa4cd50)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit ebfbd0da26)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 849f67988f)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit b034685fe8)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 37eda84469)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit ce848197e5)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit 914c8be2c0)
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit a4c0746370)
Signed-off-by: Jacob O'Mara <jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit b88dd24139)
Signed-off-by: Jacob O'Mara <jacob.omara@openfifth.co.uk>
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>
(cherry picked from commit ef2f7524c0)
Signed-off-by: Chloé Zermatten <chloe.zermatten@openfifth.co.uk>
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>
Baptiste Wojtkowski
Jacob O'Mara
Raphael Straub
Emily Lamancusa
Nick Clemens
Ayoub Glizi-Vicioso
Victor Grousset/tuxayo
Jonathan Druart
Tadeusz „tadzik” Sośnierz
Kyle M Hall
Aleisha Amohia
Marcel de Rooy
Roman Dolny
Chloe Zermatten
David Nind
Lucas Gass
Katrin Fischer
Martin Renvoize
Aleisha Amohia
Tomás Cohen Arazi
Jake Deery
Fridolin Somers