When no notice template ACQORDER was defined, you'r receive a false
positive "email sent" message. Now it will display a specific
error message instead.
Also includes 2 unit tests to test for the warn and new error code.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
With this patch it will be possible to send order information
to the vendor by e-mail. For now this feature can be triggered
manually with a button before closing the basket.
The order e-mail is based on the acquisition claim feature, but
uses a new notice template.
Test plan:
1) Vendors
A new checkbox "Contact when ordering?" was added to the vendor
page.
- Add a vendor and/or edit an existing vendor
- Verify the new option is saved correctly
- Verify the new option displays on the vendor summary page
after saving
2) Notices
The feature works with a new notice template: ACQORDER
It works with the same formatting/fields etc. as the acq claim
notice.
- Add a new notice template ACQORDER in module
'Claim/order aquisition'
- Make sure to use fields from the various offered tables
in your notice
- Verify it is saved correctly
3) Basket
- Turn on LetterLog system preference
- Create multiple order lines
- Click the 'Send order' button in the toolbar
- Verify error or success message
- Verify you received the e-mail
- Verify there is a new entry with about the sent
notice in your action_logs table
4) Regression testing...
- Verify order claims still work
- Verify serial claims still work
- Verify new serial issue notices still work
...
(I can provide additional test plans if needed)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jennifer Schmidt <jschmidt@switchinc.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Koha::GetAuthorisedValueByCode returned the
description (staff or opac) for a given authorised value.
Note that we may need a unique key to ->find instead of ->search.
Test plan:
- Checkin an item that cannot be checked in because it's lost, the
message should display the AV description
- Generate a letter with borrowers.streettype equals an ROADTYPE AV, the
description should be displayed.
- Edit a patron attribute type, the AV dropdown list should be
displayed
- Create the PA_CLASS AV category (see bug 7154) and make sure it
behaves as before when editing a patron
- The checkout list should display descriptions for LOC, LOST and
DAMAGED
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Built on top of bug 17441
Test plan:
Just have a look at the changes. Trivial.
Git grep seleted. No results.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
This patch makes the return value of SendAlerts more consistent.
It returns 1 on success, or undef || { error => 'msg' } on failure.
Needed to adjust one test in Letters.t too.
Adjusted one typo along the way (seleted).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested by running Letters.t.
Also tested SendAlerts from the interface with AutoEmailOpacUser and
memberentry (adding new patron).
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Confirming a hold to set it to waiting will result in an DBIC error in
master.
Test Plan:
1) Attempt to check in an item on hold and confirm the hold
2) Note the error
3) Apply this patch
4) Repeat step 1
5) Note there is no error!
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
https://bugs.koha-community.org/show_bug.cgi?id=14942
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
TEST PLAN
---------
1) Apply Jonathan's test patch
2) prove t/db_dependent/Letters.t
-- dies before finishing tests
3) Apply second test patch
4) prove t/db_dependent/Letters.t
-- dies before finishing tests
-- 'addalert' is changed to 'getalert'
5) Log into OPAC with database admin user.
-- see error given in comment #0
6) Apply this patch
7) prove t/db_dependent/Letters.t
-- says 'getalert'
-- all tests pass.
8) Log into OPAC with database admin user.
-- logs in, but gives warning with a nice logout button.
9) run koha qa test tools.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
No kaha qa errors
In debian display diferent error:
Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/DBI.pm line 2054.
Works as advertised
NOTE: Revised test plan, as Jonathan added useful test case.
Works as I've tested above.
Hector tested older test plan which was steps
5,6,8 and 9.
Revised test plan again while tweaking to address comment #9.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This bug is the beginning of a conversion from our current bespoke
syntax for slips and notices to Template Toolkit syntax.
This patch is the initial seed which will evolve over time.
With this addition, we can take advantage of our Koha Objects
to greatly simplify the processing of Slips and Notices over time.
Test Plan:
1) Apply this patch
2) Ensure you have the default CHECKOUT notice
3) Check out and return an item for a patron
4) Note the text of the CHECKOUT notice
5) Replace your CHECKOUT notice with the following:
The following items have been checked out:
----
[% biblio.title %]
----
Thank you for visiting [% branch.branchname %].
6) Repeat step 3
7) Note the CHECKOUT notice text matches the previous CHECKOUT notice text
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
New notice syntax works, no koha-qa errors
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Bug 14757 [QA Followup] - Change method type() to _type() for Koha objects
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Bug 14757 [QA Followup] - Change all references to Koha::Borrower to Koha::Patron
Signed-off-by: Sean McGarvey <seanm@pascolibraries.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 13622 has introduced a bug, if pref TimeFormat is 12hr and a date is
displayed in both title and content of the letter.
Test plan:
1 - Checkout an item (with default time 11:59:00 PM)
2 - Generate a quickslip
3 - Notice the time is 'AM'
4 - Apply patch
5 - Generate quickslip
6 - Note time is correct
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Letters::getletter use a package variable (%letter) to cache letter
returned by the subroutine.
I have not found any direct issues caused by that but it is safer to
remove it.
It won't be a big deal to hit the DBMS to get a valid letter when
needed.
No test plan here, just confirm that the changes make sense.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Confirm that performance loss is just a millisecond or so per
subsequent call of getletter.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
perl -p -i -e 's/^.*set the version for version checking.*\n//' **/*.pm
+ manual adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Mainly a
perl -p -i -e 's/^.*3.07.00.049.*\n//' **/*.pm
Then some adjustements
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
perl -p -i -e 's/^(use vars .*)\$VERSION\s?(.*)/$1$2/' **/*.pm
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
When resending an email from the Notices tab in Patrons, we would like
to use the recent email address.
Test plan:
[1] Look up a patron with some notices sent.
[2] Adjust the patron email address (watch AutoEmailPrimaryAddress).
[3] Resend the notice. Verify if the new address was used.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch allows to resend both sent and failed messages.
With messages in 'sent' status, we have to be careful not to accidentally send
sent messages again. With the previous patch using GET request, this was likely
to happen because of browser storing the GET parameters.
This patch changes request method from GET to POST. Instead of a simple link,
we now have a form element.
In notices.pl we redirect back to notices.pl, because with POST there is a risk
of resending the message accidentally by form resubmission at refresh.
To test, find/create a Patron that has sent or failed notices in message_queue:
1. Enable EnchancedMessagingPreferences system preference
2. Go to Patrons -> Notices
3. In the Notice column, click the title of the sent or failed message
4. Observe that there is nothing for resending the sent or failed message
5. Apply the patches.
6. Reload Notices page and repeat step 3
7. Observe that there is now a link "Resend" in the Status-column
8. Click Resend
9. Observe that the message gets into 'pending' status
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The C4::Letters module does not have a GetMessage subroutine, which
could be quite useful.
This patch adds it and simplifies the code added by the previous patch.
It also adds a few tests and fixes POD typos.
Note that ResendNotice only resends failed messages. This will avoid to
resend already sent messages (using an url from the browser history for
instance).
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch adds a link 'Resend' under a notice in 'failed' status
in the Patron's Notices tab.
By clicking the link, we will request notices.pl with parameter
"resendnotice=XXXXX" where XXXXX is message_id. In notices.pl,
we then check whether the given message is actually in 'failed'
status. If so, we use the C4::Letters::ResendMessage(123) to
change the status of the message into 'pending'. This way it
will be processed again by the cronjob process_message_queue.pl.
To test, find/create a Patron that has failed notices in message_queue:
1. Enable EnchancedMessagingPreferences system preference
2. Go to Patrons -> Notices
3. In the Notice column, click the title of the failed message
4. Observe that there is nothing for resending the failed message
5. Apply patch.
6. Reload Notices page and repeat step 3
7. Observe that there is now a link "Resend" in the Status-column
8. Click Resend
9. Observe that the message gets into 'pending' status
Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
C4::Branch::GetBranchDetail retrieved library infos, it could be easily
replaced with Koha::Libraries->find
When this change needs other big changes, the unblessed method is
called, to manipulate a hashref (as before) instead of a Koha::Library
object (for instance when $library is sent to GetPreparedLetter).
Test plan:
1/ Print a basket group, the library names should be correctly
displayed.
2/ Enable emailLibrarianWhenHoldIsPlaced and place a hold, a HOLDPLACED
notice will be generated (focus on the library name)
3/ Edit a patron and change his/her library
4/ Generate the advanced notices (misc/cronjobs/advance_notices.pl) and
have a look at the generated notices
5/ Same of overdues notices
6/ Set IndependentBranches and use a non superlibrarian user to place a
hold. The "pickup at" should be correctly filled.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Nearly all cellular providers allow a person to send an text message to a cellular
phone by sending an email to phonenumber@provider. We can leverage this capability
to add the ability for Koha to send sms messages to patrons without the need to
subscribe to an sms gateway server.
Basic plan:
1. Add a table sms_providers to the db to tell Koha what service providers are available, and what domain emails should be sent to.
2. Add borrowers.sms_provider_id to tell Koha which mobile service the patron subscribes to for the number given in smsalertnumber
3. Modify Koha to send an email rather than using SMS::Send if the driver is set to 'Email'
Test plan:
0) Get a mobile phone
1) Apply the patch
2) Run updatedatabase.pl
3) Set the value of SMSSendDriver to 'Email'
4) Go to the admin page, the "Additional parameters" area should now have the link "SMS cellular providers"
5) On this page, add some providers. Make sure to add the provider for your own cellular phone service.
Here are some examples:
Sprint phonenumber@messaging.sprintpcs.com
Verizon phonenumber@vtext.com
T-Mobile phonenumber@tmomail.net
AT&T phonenumber@txt.att.net
Only add the domain part in the 'domain' field. So for Verizon, that would be 'vtext.com'
6) Create an account for yourself, add your SMS number, and select your provider from the dropdown box directly below it.
7) Enable SMS messaging for Item check-in and Item checkout
8) Check out an item to yourself
9) Run process_message_queue.pl
10) Wait! You should receive a text message shortly, when I tested it, I received my sms message within the minute.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It could be undefined.
Test plan:
prove t/db_dependent/Suggestions.t
should return green.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
There is already a syspref called "OverdueNoticeBcc" for sending Bcc
copies of mails sent for overdues and other notices. This patch add a
new syspref ClaimsBccCopy to bcc the claimacquisition and clamissues
alerts.
Changed the wording of the system preference to:
[Send|Don't send] blind copy (BCC) to logged in user when sending
serial or acquisitions claims notices.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
In C4/Letters.pm, sub _parseletter changes values that are passed by
reference. E.g. patron's expiry date can change from iso format to
syspref format, leading to strange behaviour in the calling routines
(see Bug 15423).
This patch makes sub _parseletter work on a copy of the referenced values.
(Submitted to get feedback - is this the way to go?)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Good solution to real time bomb.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
C4::Letters::_parseletter will replace reserves.expirationdate with the
date a hold will be marked as problematic ( holds over ) if both
ReservesMaxPickUpDelay and ExpireReservesMaxPickUpDelay are enabled.
There is no reason this feature needs to rely on
ExpireReservesMaxPickUpDelay as there are many libraries that would like
to send the last day to pick up a hold in notices, but would rather deal
with the expired waiting holds manually rather than have Koha cancel
them automatically.
Test Plan:
1) Apply this patch
2) Set ReservesMaxPickUpDelay to 7
3) Disable ExpireReservesMaxPickUpDelay
4) Add reserves.expirationdate to your HOLD notice
5) Fill a hold for a patron
6) View the message, not that reserves.expirationdate is replaced
with the date the hold will be marked as problematic
Signed-off-by: Karl Holton <kholten@switchinc.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Bug 6810 - Fix QA failures
- Use KohaDates to convert dateexpiry
- remove MYSQL specifics methods for date handling in
GetUpcomingMembershipExpires
- make the script membership_expiry.pl write in Koha system logs
- add tests
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Bug 6810 - Fix QA failures:
- use Koha::DateUtils instead of Koha::Template::Plugin::KohaDates,
- Add test with syspref MembershipExpiryDaysNotice equals 0 and undef,
- fix (new) test failure (when MembershipExpiryDaysNotice is undef).
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
A new crontab based perl script to send membership expiry reminders. A
system preference controls the number of days in advance of membership
expiry that the notices will be sent on.
To Test:
1) Create a new Patron and set membership expiry date 14 days from the
date of registration.
2) Check your systemprefence ( MemExpDayNotice to 14 days default value)
3) Manual testing Run ( perl membership_expiry.pl -h)
It would give you various option:
This script prepares for membership expiry reminders to be sent to
patrons. It queues them in the message queue, which is processed by
the process_message_queue.pl cronjob.
See the comments in the script for directions on changing the script.
This script has the following parameters :
-c Confirm and remove this help & warning
-n send No mail. Instead, all mail messages are printed on screen.
Useful for testing purposes.
-v verbose
Do you wish to continue? (y/n)
4) Choose option for ex: perl membership_expiry.pl -c
5) Go to your koha database and check message_queue table you see some
results.
6) Run (perl process_message_queue.pl) it will send email to those
patron whose membership after 14 days from today.
7) Cron testing: (10 1 * * * $KOHA_CRON_PATH/membership_expiry.pl -c)
8) Set your 15 * * * * $KOHA_CRON_PATH/process_message_queue.pl
9) After running membership_expiry.pl, (process_message_queue.pl will
send emails to those patron whose membership after 14 days from
today).
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
For some needs, a librarian would like to display a datetime or
timestamp field without the time.
This patch adds filter logic in the notice/letter parsing process.
Test plan:
1/ Defined a notice using a datetime or timestamp DB field
(biblio.timestamp for instance).
2/ Generate the notice
3/ Verify that the letter is generated with the time
4/ Use the "dateonly" filter like:
<<your_table.your_field | dateonly>>
<<biblio.timestamp | dateonly>>
5/ Generate the notice
6/ Confirm the the letter is generated without the time for this field.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Updated the count of tests to 64 for t/db_dependent/Letters.t to pass
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Currently it's not possible to include information about which
issue has arrived in the serial notification notice the patron
can subscribe to from the OPAC.
The patch makes the fields from the subscription and serial
table available to the notice template.
In order to be able to print information about the correct
issue, the GetAlert has been modified to expext the serialid
as externalid when the module is issue.
git grep SendAlerts (only call with 'issue' is in Serial.pm)
To test:
- Add a subscription, select a patron notification template
- Search for the record in the OPAC
- Go to the subscription tab - More details
- Subscribe to the notification
- Edit the notice template you selected for the subscription
- add fields from subscription
- add fields from serial (serial.serialseq has the issue
information)
- Receive an issue for the subscription
- Check that you have received the notification and that
all information has been printed correctly
NOTE: notice is sent directly, not through the message_queue
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
C4::Letters::getletter() is called in tools/letter.pl by the function
delete_confirm() to display the selected notice for deletion. Due to
current implementation of getletter(), a notice that does not use
the 'email' template (but uses any/all of the other templates - sms,
print or phone) can't be deleted from the staff client.
This patch adds deletion capability for notices that do not use email
template, but uses any/all of the other templates i.e. sms, print or
phone. This also adds 2 tests to t/db_dependent/Letters.t for testing
both conditions - a) when message_transport_type is specified b) when
it is not.
Test plan
=========
1/ Go to Tools -> Notices & Slips. Add a new notice only for print,
leave 'Library' and 'Koha module' options as default selections.
Enter 'KOHA_14206' and 'Koha Test 14206' against Code and Name
respectively, and 'Test' and 'Test Message' for subject and body.
Leave the Email, Phone and SMS tabs blank. Save the notice.
2/ On the notices listing page the new notice will be listed. Try to
delete it. It will load the 'Delete notice' dialog form, but the
table will not show any data under <th>s - 'Library', 'Module',
'Code' or 'Name'.
3/ Click the "Yes, delete" button. The page will be submitted and the
Notices listing reloaded. The print-only KOHA_14206 notice should
continue to exist. This is *wrong*.
4/ Apply this patch
5/ Reload the listings page and click on the 'Delete' link for Notice
KOHA_14206. This time, it should show the data under 'Module',
'Code' or 'Name' at least.
6/ Click on 'Yes, delete'. The page should submit and the listing page
reload. This time KOHA_14206 will be gone.
7/ Run prove -v t/db_dependent/Letters.t
All tests should PASS without any error.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If the *DGST notices are sent in HTML, the items are displayed in a
single line.
To reproduce:
1/ Define a *DGST notice using the <<items.content>> pattern.
2/ Checkout at least 2 items to a patron and set the due date as today.
3/ Launch the advance_notices.pl and process_message_queue.pl cronjobs.
4/ Verify the email you will receive separates the items with a line
break.
Verify you don't find a regression for non-html letters.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Note: the display in the notices tab is misleading here,
needs to be verified checking the sent emails or database
entries in message_queue.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The emails sent via SendAlerts don't take into account HTML format.
_TEST PLAN_
Before applying:
1) Change system preference "AutoEmailOpacUser" to "Send"
2) Change "ACCTDETAILS" notice to HTML and add HTML to it
3) Create a new user with your email address
4) Note how the email displays the HTML tags as plain text
Apply patch
5) Create a new user with your email address
6) Note how the email displays the email as an HTML email
For thoroughness:
7) Change "ACCTDETAILS" notice to non-HTML
8) Create a new user with your email address
9) Note how the email displays the HTML as plain text
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The UTF-8 charset in the content type is written as "utf8" instead of "utf-8"
in SendAlerts(), which causes UTF-8 characters to display incorrectly.
_TEST PLAN_
Before Applying:
1) Edit ACCTDETAILS
2) Add some UTF-8 characters
I recommend using the following website
http://www.ltg.ed.ac.uk/~richard/unicode-sample.html
In my tests, I added the samples from Hebrew, Arabic, Basic Latin,
Latin-1 Supplement, Latin Extended-A, and Latin Extended-B.
3) Set the system preference "AutoEmailOpacUser" to "Send"
4) Create a new user account with your email address
5) Note that the email in your inbox doesn't display the Unicode
characters correctly
Apply the patch
6) Create a new user account with your email address
7) Note that the email in your inbox _does_ display the
Unicode characters correctly.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch fixes a major issue introduced by the
commit 5c4fdcf Bug 11742: A letter code should be unique.
The interface should let the possibility to create a default template
letter and some specific ones, with the same letter code (letter.code).
The patches submitted on bug 11742 tried to fix an issue based on a
(very bad) assumption: letter.code should be considered as a primary key and
should be uniq.
This patch reintroduces this behavior.
Note that the interface will block a letter code used in different
module (this is consistent not to have the same letter code used for different
needs).
This patch is absolutely not perfect, it just tries to change as less
change as possible and to use new tested subroutines.
Test plan:
1/ Verify that the problem raised on bug 11742 does not appears anymore.
2/ Verify there are no regression on adding, editing, copying, deleting
letters.
3/ Verify you are allowed to create a default letter template with a letter
code and to reuse for a specific letter (i.e. for a given library).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If you use a claimissue notice to claim serials, the generated letter
will be
<order>Title1, Author1</order>
<order>Title2, Author2</order>
...
<order>TitleN, AuthorN</order>
This patch geds rid of these tags.
Test plan:
1/ Create a claimissue notice with something like:
<<LibrarianFirstname>>
<<LibrarianSurname>>
The following issues are in late:
<order><<biblio.title>>, <<biblio.author>> (<<biblio.serial>>)</order>
2/ Generated late serial issues.
3/ Send notifications to vendor.
4/ The order tags should not exist anymore in the sent email.
You can see bug 5342 for a more detailled test plan.
Note for QA: This should have been done in GetPreparedLetter, but I did
not find a better way to do.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described. Tested having the <order> tags on one line
and also for a multi-line layout.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch simplifies the SQL query in Letters.pm for table
borrower_modifications.
It also addresses the only case this query is used in opac-memberentry.
An unused variable in Letters.pm is removed.
Test plan:
Enable selfregistration on opac.
Set verification by email to required in prefs too.
Self-register two new users.
Check the email notices generated.
Verify the new users with the tokens in their notice.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Much cleaner SQL
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Cleaner and works as described, no regressions found.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Modified:
C4/Letters.pm - remove aqbooksellers.* from SELECT statement
In Letters - SendAlerts subrotine, is safe to remove aqbooksellers.* from SELECT statement
for type=claimacquisition or claimissues. Aqbooksellers is passed to GetPreparedLetter subrotine in tables variable.
Testing:
I Apply the patch
Select Tools -> Notices and slips;
Edit ACQCLAIM;
Add :
<order>Ordernumber <<aqorders.ordernumber>> (<<biblio.title>>) (<<aqorders.quantity>> ordered) ($<<aqorders.listprice>> <<aqbooksellers.listprice>> each) has not been received.</order>
Save modifications;
Create a vendor (Acquisition module);
Create an order (Acquisition module);
Click Acquisitions -> Late orders;
Select the order created;
Click Claim order button;
Valide <<aqorders.listprice>>;
Valide <<aqbooksellers.listprice>>.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described. It's now possible to output the actual price
in the claim notice.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If no order is selected on the acq claim page when clicking
'Claim order' an ugly perl error message is displayed.
This patch corrects the behaviour to display a human readable
'No order selected'
instead.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Reworded commit message to reflect what the patch achieves.
Works as described and passes tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
DateTime::Format::DateParse (called in Koha::DateUtils::dt_from_string)
does not manage to parse 9999-12-31 if a time zone is given.
my $date = DateTime->new(year => 9999, month => 12, day => 31);
=> OK
DateTime::Format::DateParse->parse_datetime( '9999-12-31' );
=> OK
DateTime::Format::DateParse->parse_datetime( '9999-12-31',
'America/Los_Angeles' );
=> KO (~20sec on my laptop)
It should not be considered as a valid date when the letter is parsed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Note that to reproduce the problem you much be checking in items from an
account which has been restricted indefinitely (either manually or by
the overdues process). With this patch such checkins go from taking
around 50 seconds (in my test system) to around 7 to 10 seconds.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch! Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When parsing the letter content, the 0000-00-00 should not be replaced,
it's not a valid date.
Test plan:
prove t/db_dependent/Suggestions.t
should not return the following error:
0000-00-00 seems to be a date but an error occurs on generating it (The
'month' parameter ("0") to DateTime::new did not pass the 'an integer
between 1 and 12' callback
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds another check for 0000-00-00.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds a new DB field serial.claims_count
This field already exists for late orders. It makes sense to introduce
it for serial.
Test plan:
0/
a) Does not apply the patch.
b) Remove all your claimissues notices and be sure you have some serial issues
in late.
c) remove email address for the vendor you will use.
d) remove email address for the logged in user.
e) Export claims using the csv export => The selected issues will be
marked as claimed.
f) logout/login (to update the email address).
1/ Apply the patch and execute the updatedb entry.
2/ Go on the Serials > Claims page
3/ Verify that you get a warning message 'No claimissue notice defined'
4/ Verify the vendor list is correct (with the number of serial in late.
You should not get any changes here.
5/ Select one vendor and verify that the issue which was claimed before
has a claim count set to 1.
6/ Verify that you are not able to send notification to the vendor.
7/ Create a claimissue notice.
Something like:
<<LibrarianFirstname>>
<<LibrarianSurname>>
The following issues are in late:
<order><<biblio.title>>, <<biblio.author>> (<<biblio.serial>>)</order>
8/ Go on the Serials > Claims page, the warning message does not appear
anymore.
9/ Select issues. Select a notice. And "Send notification".
You should get an error (no email defined for this vendor).
10/ Add an email for the vendor.
11/ Select issues. Select a notice. And "Send notification".
You should get an error (no email defined for your user).
12/ Add an email address to your user
logout/login
13/ Select issues. Select a notice. And "Send notification".
You should get a happy message: the email has been sent!
14/ The email will contain the order tags if bug 12851 is not
pushed/applied.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, some small issues fixed in a follow-up.
Note: If you change the email address of your staff user, you will
have to log out and back in to make the change take effect.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
So notices using it (circulation, holds etc) will now use the new behaviour
To test:
1/ Edit the new systempreferences (ReplytoDefault and ReturnpathDefault)
2/ Optionally edit the branch the mail will be sent from, adding email addresses
3/ Test some mails, a circulation alert, an acquisitions claim, or a newly created borrower alert
4/ Check that the mails have the correct From, Replyto and ReturnPath set
The rules are
If the values are set in the branch use that, else use the syspref
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch makes it possible to choose a particular contact for
acquisitions and serials claims. To test:
1) Select a contact to use for claiming late orders and a contact
to use for claiming late issues.
2) Send a claim for a late order and a claim for a late issue.
3) Note that the claims went out to the proper people.
4) Run the unit test with:
> prove t/db_dependent/Letters.t
5) Sign off.
Note: the claim messages are recorded in the logs in the *Acquisitions*
module, not the Letters module as you might expect
This patch also fixes several perlcritic violations and centralizes
contact-related unit testing in Bookseller.t.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
