Script overdue_notices.pl creates a printed letter if borrower as no email.
Actually, unless --email option is used, first valid email of borrower is used. Email field should depend on AutoEmailPrimaryAddress syspref like in other letter creations.
Signed-off-by: MJ Ray <mjr@phonecoop.coop>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
Following test plan from Julien Sicot from Bugzilla:
- with patron's email address specified on "primary email"
field AND syspref "AutoEmailPrimaryAddress" on "home"
=> notice sent to patron | OK
- with patron's email address specified on "secondary email"
field AND syspref "AutoEmailPrimaryAddress" on "work"
=> notice sent to patron | OK
- with patron's email address specified on "alternate email"
field AND syspref "AutoEmailPrimaryAddress" on "alternate"
=> notice sent to patron | OK
- with patron's email address specified on "secondary email"
OR "alternate email" field AND syspref "AutoEmailPrimaryAddress" on "home"
=> no notice sent to patron, overdue notice sent to koha admin | OK
- with patron's email address specified on "primary email" OR
- with patron's email address specified on "primary email" field
AND syspref "AutoEmailPrimaryAddress" on "home"
=> notice sent to patron | OK
- with patron's email address specified on "secondary email" field
AND syspref "AutoEmailPrimaryAddress" on "work"
=> notice sent to patron | OK
- with patron's email address specified on "alternate email" field
AND syspref "AutoEmailPrimaryAddress" on "alternate"
=> notice sent to patron | OK
- with patron's email address specified on "secondary email"
OR "alternate email" field AND syspref "AutoEmailPrimaryAddress"
on "home"
=> no notice sent to patron, overdue notice sent to koha admin | OK
- with patron's email address specified on "primary email"
OR "secondary email" field AND syspref "AutoEmailPrimaryAddress"
on "alternate"
=> no notice sent to patron, overdue notice sent to koha admin | OK
- with patron's email address specified on "primary email"
OR "secondary email" OR "alternate email" field and syspref
"AutoEmailPrimaryAddress" on "first valid" => notice sent to patron | OK"secondary email" field AND syspref "AutoEmailPrimaryAddress" on "alternate" => no notice sent to patron, overdue notice sent to koha admin | OK
- with patron's email address specified on "primary email" OR
"secondary email" OR "alternate email" field and syspref
"AutoEmailPrimaryAddress" on "first valid" => notice sent to patron | OK
Note: Options for AutoEmailPrimaryAddress should be like the field names on
the patron form (primary, secondary...), but this is outside the scope of this
patch.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Right now notices for holds awaiting pickup read something like this:
You have a hold available for pickup as of 2011-02-12.
This hold will expire if it is not picked up before: 02/22/2011.
If you no longer need this item or have any questions please contact us
Both dates should be formatting based on the dateformat system preference.
Test Plan:
1) Apply patch
2) Set the HOLD notice to the following:
<<reserves.waitingdate>> / <<reserves.expirationdate>>
3) Place a hold for a patron
4) Enable the HOLD notice via email for that patron ( requires EnhancedMessaging )
5) Check the item in
6) Go to the borrower's Notices tab, check the body of the new HOLD notice,
it should have two dates separated by a '/' in the format set by the dateformat
system preference.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Patch works as advertised according to the test plan.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Tested also with the HOLD_PRINT notice.
This reverts commit 40f9914e60.
Per Colin's report (confirmed by Mathieu and Julian):
"I've had some problems with this patch. With it applied I found
overdues for multiple users getting the same user's overdue message
text, eg user 1 gets their correct message but users 2, 3 and 4
get it as well. reverting the patch corrected this. I've not tracked
down the cause as yet."
This development will add the ability for a new patron to register
himself or herself. The self-registration will attempt to match this
newly inputted data to any existing patrons and if any possible matches
are found, ask if the patron is sure he or she doesn't already have an
account at the library. A system preference may be set to prevent patron
self-registration if the system detects the possibility that the person
may already have an account.
Once the patron has registered, passing a captcha (or similar
bot-stopper), the patron will then be optionally verified a second time
via email. At this point, the patron will be able to print a temporary
library card (optional by system preference), and will be provided any
details necessary to access electronic resources (this body of text
would be a template in the slips and notices system). At the library's
choice, this new patron would either be set to a temporary patron status
(patron type set via system preference), or a fully-fledged patron
(allow patron type to be determined by age and/or other attributes).
Assuming the library uses temporary patron types for OPAC registrations,
this patron will next enter a queue and would need to physically enter
the library to verify himself and become a fully-fledged patron (most
likely by bringing in physical proof of address, etc.). The librarian
would look up the patron record and modify the patron type. If a
temporary patron has not been verified within a certain time frame
(defined by a system preference), the patron record will be deleted
from the system via a cron job.
For registered patrons, the system will allow each person to also
update his or her personal data via the OPAC. When a patron updates his
or her information, the changes will be entered into a queue to be
verified by a librarian (preventing a patron from inputting obviously
bogus data). The staff client home page will display the number of
patron records with changes awaiting approval. A librarian would then be
able to click through a list of modification requests, and approve or
deny each (with approval and denial alerts being sent to the patron via
the standard messaging system).
NEW SYSTEM PREFERENCES
* PatronSelfRegistration
* PatronSelfRegistrationDetectDuplicates
* PatronSelfRegistrationVerifyByEmail
* PatronSelfRegistrationPrintTemporaryCard
* PatronSelfRegistrationUseTemporaryStatus
* PatronSelfRegistrationExpireTemporaryAccountsDelay
NEW NOTICE
* Verify by email notice
NEW SLIP
* Temporary card slip
NEW CRON JOB
* delete_expired_opac_registrations.pl
- Deletes patrons that have not been upgraded from the temporary
status within the specified delay
* delete_unverified_opac_registrations.pl
- Deletes the unverified patrons based on the length of time specified
in the PatronSelfRegistrationExpireTemporaryAccountsDelay
The patron will register from self_registration.pl, linked off opac-main.pl if enabled. The registration page will be translatable to other languages in the same way that existing templates are.
Test Plan:
1) Enable PatronSelfRegistration
2) Set PatronSelfRegistrationExpireTemporaryAccountsDelay to a number
of days
3) Create a self-registered borrower category
4) Set PatronSelfRegistrationUseTemporaryStatus
5) Set PatronSelfRegistrationVerifyByEmail to "Don't require"
6) Go to OPAC, log out if logged in.
7) You should see the "Register here" link below the login box
8) Attempt to register yourself
9) Verify you can log in with your temporary password.
10) Set PatronSelfRegistrationVerifyByEmail to "Require"
11) Attempt another self-registration
12) Check the messages table, you should see a new message with a
verification link.
13) Copy and paste the link into a web browser to verify the registration
14) Log in with the given credentials to verify the account was created.
Test Plan - Part 2 - Borrower Modifications
1) Log in to OPAC, go to "my personal details" tab.
2) Make some modifications to your details.
3) Repeat steps 1 and 2 for two more borrowers.
4) Log in to Koha intranet with a user that can modify borrowers.
5) At the bottom of mainpage.pl, you should see:
Patrons requesting modifications: 3
6) Click the link
7) Approve one change, deny a different one, and ignore the third, then
submit.
8) Check the records, you should see the changes take affect on the
approved one, and no changes to the other two. You should also see
"Patrons requesting modifications: 1" at the bottom of mainpage.pl
now.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Bug 7067 - OPAC Borrower Self Registration - Followup
* Rename PatronSelfRegistrationUseTemporaryStatus to PatronSelfRegistrationDefaultCategory
* Hide register link unless PatronSelfRegistrationDefaultCategory is set.
* Add invalid token page
* Add documentation and switches to cron scripts
* Add required fields check for editing exiting patrons
* Don't force require email address for existing patrons when
PatronSelfRegistrationVerifyByEmail is enabled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Passed-QA-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The patches for bug 7001 removed the parseletter subroutine from
C4::Letters without updating the talking tech script to use the
new alternative. This patch rectifies that situation.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Bug 8378 - <fine> syntax broken NFC and charset utf8
NFC normalize enqueued letters and add content-type charset=utf-8
This prevents utf8 codes from causing mysql to truncate the 'content'
from the point of certain codes, when stored in the message_queue table.
This was happenning with the currency symbol generated by
Locale::Currency:Format currency_format routine. NFC normalization
was only done on the attachment content with its content-type
containing "text", as in text/plain.
For emails AND attachments, the charset="utf-8" was added to the
content-type so mail clients would correctly iterate the utf8 codes,
thus preventing mobijake.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Ran through test plan before and after applying patch. Verified
that fine syntax does not work pre-patch and does work post-patch
for both direct emails and emails to the KohaAdminEmailAddress.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Patch introduces a check for C4::Context->userenv in Letters.pm, so that script doesn't fail when it calls to C4::Context->userenv->{branch}, when run from shell.
Without the check, Advanced Notices, Item Due, and Overdues fail to generate.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Perlcritic reported the following errors:
Subroutine prototypes used at line 96, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 120, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 152, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 173, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 190, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 227, column 1. See page 194 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 228, column 31. See page 199 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 229, column 31. See page 199 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 236, column 9. See page 199 of PBP. (Severity: 5)
Subroutine prototypes used at line 668, column 1. See page 194 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 669, column 27. See page 199 of PBP. (Severity: 5)
Subroutine prototypes used at line 719, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 865, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 899, column 1. See page 194 of PBP. (Severity: 5)
Subroutine prototypes used at line 981, column 1. See page 194 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 982, column 28. See page 199 of PBP. (Severity: 5)
Subroutine prototypes used at line 1000, column 1. See page 194 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 1001, column 27. See page 199 of PBP. (Severity: 5)
"return" statement with explicit "undef" at line 1004, column 9. See page 199 of PBP. (Severity: 5)
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Adds the option -s/--split to enable notices to be separated
into different files by borrower home library.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
For the CHECKIN and CHECKOUT notices, any data that is issue specific
does not show. For example, date due.
For CHECKOUT, this is caused not passing in the issues table as part
of the 'table' hash used by C4::Letters::GetPreparedLetter.
For CHECKIN notices, we need the old_issues table instead, as the item
has already been returned.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
passes tests, correct information shows in notices.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch avoid enqueuing messages that have an empty body. It can
happen when letter is empty or becomes empty after being processed by
parseletter
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Implements support for Talking Tech I-tiva phone notification for OVERDUE, PREDUE and HOLD notifications.
Overdues respect triggers as configured for the patron's branch.
Predue and Holds notifications respect patron's messaging preference choices.
A new column for phone notification is added if the TalkingTechItivaPhoneNotification system preference is turned on
Record of phone messages being sent to patrons is added to the patron's Notices
tab; notice of success or failure can be retrieved from I-tiva.
See the TalkingTech.README for installation and set-up instructions.
Aside from the control system preference, and the necessary changes to Messaging Preferences
forms to make use of phone notifications, the bulk of the code resides in external
cronjobs.
TalkingTech_itiva_outbound.pl generates the Spec C file to send to I-tiva. Actual transmission
of the file must be handled by the system administrator.
TalkingTech_itiva_inbound.pl processes the received Results file from I-tiva. Getting the
file from I-tiva to Koha is the job of the system administrator, as well.
Both scripts have a --help option with full documentation.
The only necessary change to core Koha behavior is in C4::Letters::EnqueueLetter. The return
value was changed from 0 or 1 (successful addition of letter to message_queue or not), to the actual
insert ID of the letter. This was required by the outbound script to present a unique Transaction ID
for the notice added to the patron's record (so a 'sent' or 'failed' status could be updated). Since
the dbh and sth are not shared, and the last_insert_id() command is table-specific, this should be thread-safe.
No changes are necessary to any parts of Koha, as all usage of EnqueueLetter currently ignores the return value.
To Test:
1. Turn on TalkingTechItivaPhoneNotification system preference
2. Verify that 'phone' is now a valid notification option for patrons on both staff and OPAC side
3. Attempt to set a 'phone' preference for PREDUE or HOLD messaging; attempt should succeed
4. Set up the patron for notices to triggers:
a. include checked out items due in a range of days, including the value set up in their messaging preferences.
b. place several holds, some in position, others waiting for pickup, others in transit.
c. set the patron up to have overdues, overdue by a range of days that includes the delay values for
the patrons branch and categorycode
5. Run TalkingTech_itiva_outbound.pl --type=RESERVE --type=PREOVERDUE --type=OVERDUE --outfile=/tmp/talkingtechtest.csv
The resulting talkingtechtest.csv file should include all the items due on X days (where X is the patrons' preference),
and none of the ones due in other increments. Similarly, overdues messages should be added for each item due by a delay
value as configured; overdues of other numbers of days should be ignore. Holds that are waiting pick up or in transit should
have messages, those still pending should not.
Messages should be added to the patron's notices tab for each issue sent. Verify these messages exist, and all Notices
tokens are replaced with appropriate information.
Repeat, this time with 4c making use of the default branch overdue triggers, instead of branch-specific triggers.
To test the inbound script, create a CSV with rows in the format "<<Message_id>>","<<SUCCESS or FAIL>>"
Message ID should correspond to the final column of the talkingtechtest.csv file (the transaction id) for the message.
Primary Authorship: Ian Walls
Additional modifications: Kyle M Hall
http://bugs.koha-community.org/show_bug.cgi?id=4246
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Tested and in use in production by two public libraries : Middletown
and Washoe. Both have given their sign off, but don't have git to
actually sign off.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
- sending claim mails works now
- claim counter is not increased when vendor has no email address
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
- Fix sql syntax error
- Fix Encoding
- SendAlerts must return an error if no email is defined
- Get error if no email in memberentry
http://bugs.koha-community.org/show_bug.cgi?id=7001
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
solves my comment 89: when you have a "mandatory" notice defined for a given library, it's not possible to delete it (and switch back to the "default" notification). isn't this a (small) bug ? was it intended ?
thanks!
Branches can have their own version of notices - added branchcode to
letter table.
Support html notices - added is_html to letter table.
Support for borrower attributes in templates.
GetPreparedletter() is the interface for compiling letters (notices).
Sysprefs for notice and slips stylesheets
Added TRANSFERSLIP to the letters
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This bookseller has no email shows up correctly, when vendor has
no email address.
Small change made: Changed bookseller to vendor.
This patch fixes some minor problems found in late order management:
1) Silences 2 warns in Letters.p
After patch is applied no more warns should show up in the logs.
2) Fixes check/uncheck al
When limiting on one vendor the checkbox in the last header column
was doing nothing. I changed the checkbox to 2 links 'check all' and
'uncheck all' as it's done in other templates.
3) Email has been sent
The message was hardcoded into the lateorders.pl file and not
translatable.
I moved it to the template and changed the wording slightly.
Note: The error message 'The bookseller has no email' comes from
Letters.pm. I didn't change that, because I was not sure where it is
used. The error message as is can not be translated and should be
moved into the templates too.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
FIX encoding problem
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Umlauts and diacritics now show up correctly in generated claims notices.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch adds 2 columns in the aqorders table :
- claims_count : number of claims for an orders
- claimed_date : date of the lastest claim
In the lateorders.pl table, you can not select orders from different
supplier because there is just one letter sent after clicking the "Claim
order" button. So, it's logic that you want to select only orders from
this supplier.
Modification in C4/Letters.pm:
refactoring code for claimacquisition and claimissues letter type.
Now, fields for theses letters check the table name. It's not possible
to chooce aqorders.title, this field doesn't exist !
Furthermore, you can add a <order> tag around your item fields, like
this :
-- Begin example
<<LibrarianFirstname>>
<<LibrarianSurname>>
<<aqbooksellers.contact>>
<<aqbooksellers.address1>>
<<aqbooksellers.phone>>
<<aqbasket.basketno>>
<<aqbooksellers.phone>>
<order>Library : <<items.homebranch>>
In your possesssion : <<biblio.author>>. <<biblio.title>>.
<<biblioitems.publishercode>>, <<biblioitems.publicationyear>>.
Callnumber : <<items.itemcallnumber>>. doc type : <<items.itype>>
Barcode : <<items.barcode>>
Date for the return : <<items.onloan>>.</order>
<<LibrarianSurname>>
-- End example
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Updates to_address in message queue when sending an email (when needed).
Signed-off-by: Koustubha Kale <kmkale@anantcorp.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
In parseletter_sth, the suggestions table was defined twice. The first time (which
is the only definition to get called, as it matches first then exists), defined the
primary search keys as borrowernumber and biblionumber. This is incorrect; the only
usage of the suggestions table tokens is with suggestionid as the key. This is defined
further down the if/then chain.
This patch removes the erroneous sth query definition.
To test:
1. Place a suggestion with a patron account with a configured email you can access
2. Approve or reject it
3. Verify the message you receive contains suggestion tokens (like title, author and reason)
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Suggestion mails for accepted, rejected and ordered look good now.
I couldn't test the suggestion mail AVAILABLE (bug 7096), but
assuming this would work too.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Adding support for including fields from the Issues table in advanced due notices.
This is primarily to allow the inclusion of the due date for each item in the
advanced due notice, but will allow the inclusion of any field from the ISSUES
table.
This also adds code to exclude timestamp fields as these are irrelevant to the
end user in this context.
Note: Documentation should be updated to reflect the availability of the additional
fields in all circulation notices.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This patch adds support for using a gmail account as an SMTP server.
It includes a basic HOWTO.
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This patch enables the ACCTDETAIL notices (and any branch-specific derivatives) to use
<<branches.*>> and <<borrowers.*>> tokens
This patch also attempts to send the email from the branch email first, falling back to
KohaAdminEmailAddress if no branch email exists.
To test:
1. Enable AutoEmailOpacUser system preference
2. Add <<branches.*>> tokens to the ACCTDETAIL notice
3. Create a new patron, including:
a. test email address in the field matching your AutoEmailPrimaryAddress syspref value
b. username and password (required to send a notice)
c. any other required fields to save the record
4. Check you inbox. Notice should send instantly (no need to run process_message_queue.pl)
Signed-off-by: Jared Camins-Esakov <jcamins@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Your suggestion notices template needs to contain things like
<<suggestions.title>>
<<suggestions.author>>
etc
Squashed commit of the following:
commit 3f4278bbe8d4c68be9f72d50e1eef6a411dc873d
Author: Chris Cormack <chrisc@catalyst.net.nz>
Date: Fri Aug 13 09:41:34 2010 +1200
bug 4211 parsing the letter before we enqueue it
commit ecdc0ff34c1aa9b96b68d541423ca693e2d63e67
Author: Chris Cormack <chrisc@catalyst.net.nz>
Date: Fri Aug 13 09:32:09 2010 +1200
Changing the query to fetch suggestions data, this is needed for suggestion mail to be sent
commit ece11d015b945ce119cf7cbc5e2563f4bc8aecf9
Author: Owen Leonard <oleonard@myacpl.org>
Date: Thu Aug 12 12:36:26 2010 -0400
Fix for Bug 4211, Acquisitions actions on suggestions don't generate email
Assuming 1) The patch for Bug 5126 is approved and 2) Suggestions
notices are added by hand (or from default sql--see Bug 5127) this
correction should get suggestions notices properly enqueued.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
commit 5c3bbe7d557b1994be72518746217fc6fc4e5b83
Author: Owen Leonard <oleonard@myacpl.org>
Date: Thu Aug 12 12:27:33 2010 -0400
Fix for Bug 5126 - Suggestions module missing from "add notice" form
- Adding "suggestions" entry
- Re-ordering options in alphabetical order
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
This is done by saving the notices in the message_queue table with
type 'print'. The notices are generated from a notice named
HOLD_PRINT. At the end of the day, they are dumped to an HTML file and
marked as sent by a new cronjob.
This setup is intended to be temporary; modules/batch/ shouldn't be around
forever.
Mandatory SQL:
INSERT INTO message_transport_types (message_transport_type) values ('print');
Note: overdue_notices.pl really needs to be completely re-written.
The script does not process all fields advertised in tools/letter.pl
This patch adds code to process all fields advertised as well as any
from the items table.
It also adds two additional tags for use in the letter templates:
<item></item> which should enclose all fields from the biblio, biblioitems,
and items tables.
<fine></fine> which should be enclosed by the item tag and should
enclose a currency identifier per ISO 4217. If this tag is present with
a proper identifier, the fine for that item will be displayed in the
proper currency format. Note: ISO 4217 changes from time to time therefore
all currencies may not be supported. If you find one that is not
supported, please file a bug with the Locale::Currency::Format author
Tan D Nguyen <tnguyen at cpan doe org>.
An example of the implimentation of these two tags in a notice template
might be like:
The following item(s) is/are currently overdue:
<item>"<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <fine>GBP</fine></item>
Which, assuming two items were overdue, would result in a notice like:
The following item(s) is/are currently overdue:
"A Short History of Western Civilization" by Harrison, John B, 909.09821 H2451, Barcode: 08030003 Fine: £3.50
"History of Western Civilization" by Hayes, Carlton Joseph Huntley, 909.09821 H3261 v.1, Barcode: 08030004 Fine: £3.50
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
The return from Mail::Sendmail should always be checked
Output the error message if it fails so we have some
indication of where to start looking if it fails
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
If a global syspref OverdueNoticeBcc is present, send overdue notices to
this address. This allow a library to track and gather all outgoing
overdue notices.
Enhancing C4::SearchSuggestion
And changing its API
Changing C4::Suggestions API taking a hashref for NewSuggestion and ModSuggestion
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
This update the way Member is added and editing so that import and Edition
could be best automatized
GetMember evolves and allow ppl to serach on a hash of data
Adding SQLHelper A new package to deal with INSERT UPDATE and SELECT
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
If a patron has no email address, we need to avoid stockpiling all
their messages indefinitely. Otherwise they get mailbombed when
their email IS added.
Note that overdues should not be affected, since the overdues job
checks whether the patron email exists before sending the message
(falling back to the admin). The other messaging features are the
targets affected by this patch.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
Subroutine arguments enforced w/ with more checks, explicit return undef where warranted.
Placeholders used in SQL where applicable.
One logical error corrected :
- next MESSAGE if ( lc( $message->{'message_transport_type'} eq 'rss' ) );
+ next MESSAGE if ( lc($message->{'message_transport_type'}) eq 'rss' );
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
The re-creation of statement handles for the same queries, repeatedly,
seriously degrades the performance of notices. This introduces new
class-level caching to avoid that problem.
Note: initial provisions
to do the same with caching of COLUMNS information about tables is
also included, but this would probably be most usefully implemented
in C4::Context (or a separate more central module). The benefits of
caching that info would probably be even greater. Note that this
proposed implementation might be obsoleted by ORM integration, where
DB structure info would already be cached.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
