Replace occurences of 'Notices & slips' with 'Notices and slips'
(replacing '&' and '&' with 'and'), as per the terminology
guidelines.
See the terminology list:
https://wiki.koha-community.org/wiki/Terminology
Test plan:
1. Find occurrences of 'Notices & slips':
- git grep 'Notices & slips' -- :^misc/translator/po
- git grep 'Notices & slips'
2. Review places in the staff interface where 'Messages & slips' is
displayed:
- Tools home page
- Tools > Notices & slips: page title and breadcrumb
- Other breadcrumbs:
. Tools > Notices & slips > New notice > [select any module]
. Tools > Notices & slips > [select Edit for any notice]
. Tools > Notices & slips > [select Delete for any notice]
3. Review other occurences:
. The cron job description for misc/cronjobs/holds/holds_reminder.pl:
misc/cronjobs/holds/holds_reminder.pl -man (scroll down to the
description)
. The TalkingTech README file:
vi misc/cronjobs/thirdparty/TalkingTech.README
4. Apply the patch.
5. Re-run the grep queries from step 1 - no occurences are now found.
6. Review places where 'Notices & slips' was found in steps 2 and 3 -
these should all be replaced with 'Notices and slips' and should
read correctly.
7. Sign off!
Alernative: review the diff for the patch and check that occurences of
'&' and '&' are replaced with 'and' and the updated text reads
correctly.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit d614a0199b)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch records the current context to the background_jobs table at
enqueue time and then uses that record to set the context at process
time.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit bde3a32277)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Is that correct?
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 44b74010b1)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We need to set the userenv when we process the jobs. It is useful for
stats (at least)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 0f2425a243)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch corrects missing import
To test:
1 - perl misc/cronjobs/holds/auto_unsuspend_holds.pl
2 - It dies
Undefined subroutine &main::AutoUnsuspendReserves called at misc/cronjobs/holds/auto_unsuspend_holds.pl line 38.
3 - Apply patch
4 - run again
5 - It succeeds!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 6c315c164d)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Without this patch, the script won't delete any
unused authorities, but gives an error instead
and dies:
Undefined subroutine &main::DelAuthority called at ./misc/migration_tools/remove_unused_authorities.pl line 98.
To test:
- Run from koha-shell:
./misc/migration_tools/remove_unused_authorities.pl -t
- Verify several authorities are reported as unused
- ./misc/migration_tools/remove_unused_authorities.pl -c
- Verify the error message is shown when the first unused
authority is found and the script stops
- Apply patch and rerun:
./misc/migration_tools/remove_unused_authorities.pl -t
- Verify the error is gone, the script finishes and auhorities
are deleted
https://bugs.koha-community.org/show_bug.cgi?id=30936
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit df393b38b8)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Silly mistake, 'delete if verbose' must be 'delete if confirm'
Test plan:
Try the cleanup_database.pl script to delete transfers and old issues.
Using --transfers --old-reserves and the --confirm flag the entries must be
removed
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit a6166405c7)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch fixes the broken commit_file.pl script.
It doesn't deal with commiting the import from the UI.
To test:
1. Pick a file for staging:
$ kshell
k$ misc/stage_file.pl --file TestDataImportKoha.mrc
=> SUCCESS: All good
2. Commit!
k$ misc/commit_file.pl --batch-number 1
=> FAIL: You see
DBIx::Class::Storage::DBI::_exec_txn_begin(): DBI Exception: DBD::mysql::db begin_work failed: Already in a transaction at /kohadevbox/koha/C4/Biblio.pm line 303
3. Apply this patch
4. Repeat 2
=> SUCCESS: Commit succeeds
5. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: (QA follow-up) Remove unexisting parameters of BatchRevertRecords
There is no interval and callback as in BatchCommitRecords.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: Call progress callback one last time to confirm comppletion
Previously after finishing the loop we were still in a transaction that never completed - we should report progress when done
one final time to commit the last records
To test:
1 - Stage a file with > 100 records
2 - Commit file
3 - Confirm batch is imported and no records left as staged
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: Fix import from staff client
same test as before, but via the staff client
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 29325: Handle the transaction in BatchCommitRecords
Requiring the callback to commit was breaking reversion, and likely elsewhere
Let's simplify and say that the routine iteself will handle the txn and commit
TO test:
1 - Stage a file
2 - Import a file
3 - Revert a file
4 - Test staff client and command line
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 29325: (QA follow-up) Tidy up
tools/manage-marc-import.pl: sub commit_batch does no longer need $schema
tools/manage-marc-import.pl: sub revert_batch: calling BatchRevertRecords which has no interval and callback
misc/commit_file.pl: sub print_progress_and_commit does no longer commit, renamed
misc/commit_file.pl: sub print_progress does no longer have a schema parameter
misc/commit_file.pl: sub revert_batch reported deleted items as added
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit f279cdd30f)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
1) Apply patch and notice the following error is gone:
$ perl misc/cronjobs/import_webservice_batch.pl
Undefined subroutine &main::GetStagedWebserviceBatches called at misc/cronjobs/import_webservice_batch.pl line 46.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
In holds_reminder.pl, the script loops over all available branchcodes. For each iteration of the loop, if not using the calendar, the script subtracts the days parameter from the current date to get the waiting date threshold. The problem is that this method alters the DateTime object in $date_to_run, so for each iteration of the loop, the waiting date becomes farther and farther in the past, when it should always be the same!
The solution is to either clone the "date to run" for each call to subtract, or to move it out of the loop since it doesn't need to be recalculated each time.
Test Plan:
1) Become the koha user using koha-shell
2) Run DBIC_TRACE=1 misc/cronjobs/holds/holds_reminder.pl --days 7
3) Note in the queries that for each loop, the waiting date is different
4) Apply this patch
5) Run the command in step 2 again
6) Note the queries all now have the same waiting date threshold!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 28514 changed the way holds_reminder.pl searches for templates, using a direct search for letters,
but should be using find_effective_template instead. Now, if a branch specific template does not exist,
it will skip that branch.
Test Plan:
1) Ensure you only have the default HOLD_REMINDER template
2) Become the koha user using koha-shell
3) Run misc/cronjobs/holds/holds_reminder.pl --days 7 -v
4) Note that the script skips every branch
5) Apply this patch
6) Run the command in step 3 again
7) Note the script doesn't skip over any branches
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
TO test:
1 - Check out an item marked for autop renewal to a patron and make it overdue
2 - Set system preference AutoRenewalNotices to follow messaging prefs
3 - set that borrower to receive both email and SMS AUTO_RENEWALS_DGST
4 - confirm your AUTO_RENEWALS_DGST does not have SMS content but does have email
5 - run the auto_renew cron
6 - item is renewed, but error from cron, and cron dies:
No circulation AUTO_RENEWALS_DGST letter transported by sms at /kohadevbox/koha/C4/Letters.pm line 583.
no letter of type 'AUTO_RENEWALS_DGST' found for borrowernumber 5. Please see sample_notices.sql at misc/cronjobs/automatic_renewals.pl line 305.
Can't use string ("1") as a HASH ref while "strict refs" in use at /kohadevbox/koha/C4/Letters.pm line 898.
7 - Apply patch
8 - Make item eligible for auto renewal agian (or checkin/checkout)
9 - Run the cron
10 - There is still 2 warn, but cron does not die:
No circulation AUTO_RENEWALS_DGST letter transported by sms at /kohadevbox/koha/C4/Letters.pm line 583.
no letter of type 'AUTO_RENEWALS_DGST' found for borrowernumber 5. Please see sample_notices.sql at misc/cronjobs/ automatic_renewals.pl line 305.
11 - Patron receives email and item is renewed
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
With this patch you can access items using:
Number of items [% items.count %]
[% FOR i IN items %]
[% SET checkout = i.checkout %]
Item [% i.itemnumber %] is due on [% checkout.date_due | $KohaDates %]
[% END %]
== test plan ==
1. Add the following to PREDUEDGST and DUEDST:
Number of items [% items.count %]
[% FOR i IN items %]
[% SET checkout = i.checkout %]
Item [% i.itemnumber %] is due on [% checkout.date_due | $KohaDates %]
[% END %]
2. Find a patron and set there messaging prefs 'Item due' and 'Advanced
notices' so they get an email and 'digest only'.
On 'Advanced notices' set Days in advance to 1.
3. Check some things out to a patron and make them due tomorrow.
4. perl /kohadevbox/koha/misc/cronjobs/advance_notices.pl -v -c
5. Check the patrons notices and make sure the PREDUEDGST looks right.
6. Check some things out to a patron and make them due today.
7. Repeat 4.
8. Check the patrons notices and make sure the DUEDGST looks right.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Depends on Bug 30373
This patch adds *-installer-UNIMARC.po translation files.
For fr, it, uk and ru languages matching strings have been
extracted from master (fr-FR) or 21.05 (it,ru,uk) UNIMARC SQL
files. The mentioned languages shows some level of completion:
fr-FR 76%
ru-RU 61%
it-IT 55%
uk-UA 54%
To test:
1) Apply the patch
2) Verify new files are present
misc/translator/po/*-installer-UNIMARC.po
3) Verify fr-FR, it-IT, ru-RU and uk-UA files
have translated strings (inspect the files or use poedit)
4) Install any of those languages, ej.
misc/translator/translate install fr-FR
then do a clean UNIMARC install and verify that
authority and bibliographic frameworks shows translated
strings.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a new translation file, *-installer-UNIMARC.po
To test:
1. On top of all previous patches
2. Apply this patch
3. Create (or update) some language
Ej.
misc/translation/translate create xx-YY
verify new file misc/translation/po/xx-YY-installer-UNIMARC.po
4. Install new language
misc/translation/translate install xx-YY
verify new dirs:
installer/data/mysql/xx-YY/marcflavour/unimarc/{mandatory,optional}
5. Repeat install procedure selecting xx-YY language and UNIMARC
verify all frameworks are present
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates all references to the former ACCTDETAILS notice to
use the new WELCOME email notice instead.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds welcome email for new users support to the command line
patron import tool.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Why require `job_`.. it's easiery to just use 'queue' and we have 'job'
from the context of the script we're calling. This also inproves
consistency between the debian commands and the script params.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch renames the queues so the default is the **real-time** one, and
the other (*long_tasks*) is kept for **long running** tasks.
All current *batch* tasks are explicitly assigned to the **long_tasks**
queue as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a new column background_jobs.queue, which default to
'default'
By default, new jobs are enqueued into this default queue, and the
background job worker will subscribe to the default queue unless told
otherwise by the --job-queue option
The new job UpdateElasticIndex is automatically enqueued in another
queue named 'index'
So you can have 'default' worker with
misc/background_jobs_worker.pl
and a dedicated indexing worker with
misc/background_jobs_worker.pl --queue index
This is to address bug 27344 comment #15
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This will let sysop adjust the number of workers and how they want to
manage them.
For instance one could want to have one worker for ES indexation and
another worker for other jobs, to prevent ES index to be stuck behind
bigger batch process.
Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.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: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch just deletes translation files left behind when removing
support for NORMARC.
To test:
1) Apply the patch
2) Verify there are no more *-marc-NORMARC.po files
on misc/translator/po/ dir
No consequences are expected.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
EDIFACT is an abreviation, so it should be ALLCAPS.
* Electronic Data Interchange for Administration, Commerce and Transport
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The last run of a report is updated only if method execute_query() is
called with report_id.
This whas missing for :
- when report is run publicly
- when report is sent by email
- when report is exported
Patch changes the method signature to use a hash of params, in order to
easily avoid some params.
Test plan :
1) Create a report.
2) Run report.
3) Check the report listing. Confirm that the last run info on the report is updated.
4) Make report public.
5) Run report via public url.
6) Check the report listing. Confirm that the last run info on the report IS NOT updated.
7) Schedule the report to run at a given time and e-mailed to an address.
8) After the report runs at the scheduled time, check the report listing. Confirm that the last run info on the report IS NOT updated.
9) Run report.
10) Export results.
11) Check the report listing. Confirm that the last run info on the report IS NOT updated AT THE TIME OF THE EXPORT.
Questionable (I don't know if this is addressed):
12) Run report on backend through a cron job and send results via e-mail.
13) Check the report listing. Confirm that the last run info on the report IS NOT updated.
14) Apply patch.
15) Rerun steps 2-13. Confirm that steps 3, 6, 8, 11, and 13 DO UPDATE the last run info.
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Use of uninitialized value in string ne at misc/cronjobs/automatic_renewals.pl line 193.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
For any borrower, we are either:
1 - following their preference, and that should set 'wants_email'
OR
2 - Never sending / following the cron, and can determine 'wants_email'
from the 'send_notices' variable
This patch adds an 'else' if not using preferences to accomplish this
Follow test plan on previous patches
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds two new variables:
$wants_email and $wants digest
These are used to simplify checks on whether notices should be sent
To test:
1 - Apply patch
2 - Confirm notices are not sent of pref is 'cron' and send_notcies flag not set
3 - Confirm notices are sent if pref is cron and send_notices flag is set and borrower
does not have preference set for auto renewals
4 - Confirm notices not sent if pref is set to follow messaging preference and borrower
does not have preferences set for auto_renewals
5 - Confirm regular notices sent if pref is set to follow messaging preferences and borrower
does have the preference set but not digest
6 - Confirm digest notices sent if pref is set to follow messaging preferences and borrower
does have the preference set and wants digest
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Currently, the code sends an email to the patron when there is any error that is not
'too_soon' - we also don't include issues that are 'too_soon', so emials may be missing information
This patch changes the code to:
1 - push all issues that were checked to the report when a borrower wants a digest
2 - adds a variable to track when any of the issues has been updated, and checkes this when
sending digests
3 - if nothing has been updated, no report is sent to the patron
To test:
1 - Checkout an item, marked for autorenewal, backdated to be overdue to a patron
2 - Set preferences
AutoRenewalNotices = 'according to patron messaging preferences'
EnhancedMessagingPreferences = 'Allow'
3 - Set the patrons preference for auto renewal to email+digest
4 - Ensure the patron has an email
5 - Place an item level hold for another patron on the issued item
6 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
7 - Check patron record/notices tab
8 - Note item not renewed, patron notified
9 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
10 - Note item not renewed, status not changed, patron notified again
11 - Apply patch
12 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
13 - Item not renewed, patron no notified
14 - Checkout another item marked for auto renewal to the patron, but due in the future
ensure it is outside of 'no renewal before'
15 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
16 - Patron not notified, items not renewd
Change to status of 'auto_too_soon' is not notified
17 - Checkout a third item, marked for auto renew, overdue
18 - place an item level hold for another patorn on third item
19 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
20 - patron is notified, nothing renewed, all statuses reported
21 - cancel the item level hold on third item
22 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
23 - item renewed, patron notified, all statuses reported
24 - perl misc/cronjobs/automatic_renewals.pl -v --confirm
25 - nothing renewed, patron not notified, only change is one issue 'auto_too_soon'
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the script pass the default SMTP transport to the
->send_or_die call.
The default is picked as this is the current behavior. New enhancements
could add the *library_id* to the message_queue table, and allow using
different transports depending on that. But it is out of the scope of
this bug.
To test:
1. Verify messages are being sent.
2. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
JD amended patch: revert
- unless $format =~ m[^html$|^csv$|^ods$];
+ unless $format =~ m/^html$|^csv$|^ods$/;
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the cronjob script use Koha::Email and thus relying on
configured SMTP settings instead of just trying localhost.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If the MARC record does not contain the correct biblionumber of
biblioitemnumber, the script will display the following warning:
== Bibliographic records have MARCXML without biblionumber or biblioitemnumber ==
* Biblionumber 4242 has '1' in 999$c
* Biblionumber 4242 has biblioitemnumber '4242' but should be '1' in 999$d
=> The bibliographic records must have the biblionumber and biblioitemnumber in MARCXML
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
