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>
If multiple registrations are submitted, the first patron to register
will be used for the first patron to click the registration confirmation
link!
Test Plan:
1) Submit 2 new patron registrations
2) Use the confirm link from the 2nd registration
3) Note you end up registering as the first submitted registration
4) Apply the patch
5) Repeat steps 1 and 2
6) Note you are now confirmed correctly
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Test plan appears to work fine, I have a feeling the sql could be
written better but can't come up with it on a Sunday morning
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and fixes a critical bug.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
At the moment, $dateonly is set to true when $1 is defined. However,
since the regex capture group only includes the time, this flag will
only be set when there is a value that includes a time.
In effect, this means that timestamps are reduced to dates only,
while dates have 00-00-0000 added to them.
This patch keeps the logic but reverses the values, so that $dateonly
will default to true unless $1 is defined.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Overdue notices are using the MySQL date format and not the dateformat
in the system preferences.
Test Plan:
1) Enable checkout notices for a patron, make sure the date due is in
the notice.
2) Check out an item to that patron, note the date is in the mysql
datetime format
3) Apply this patch
4) Check out another item to the patron, not the date is now in the
preferred date format.
Signed-off-by: David Cook <dcook@prosentient.com.au>
I love this patch! It is the best solution to this problem that I've
seen. I think it is set up to perfectly handle dates in the notices.
Unfortunately, the $dateonly flag is backwards, so the time is stripped
from timestamps and 00:00:00 is added to dates without times.
I'm adding a follow-up to reverse the setting of this flag.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
In C4::Letters::GetLetters, the code filter was not used as a query
parameter.
Moreover, the JS code was buggy. We only need to check the letter code,
except if it is an edit and the letter code has not been changed.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This patch is a dirty way to fix a design issue on notices.
Currently the code assumes that a letter code is unique. Which is wrong,
the primary key is module, code, branchcode.
Maybe we should add a primary key (id) for the letter table in order to
pass the id to the template and correctly manage the letter code
duplication.
Test plan:
Try to duplicate a letter code using edit, add and copy actions.
If you manage to do it, please describe how you did.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
The GetLetters subroutine should return an arrayref with different
letters for a module.
Test plan:
0/ Delete your notices with module=claimacquisition, claimissues,
serial
1/ Go on the late orders page (acqui/lateorders.pl) and verify you
cannot choose a notice for claiming
2/ Create a notice with module=claimacquisition
3/ Go on the late orders page (acqui/lateorders.pl) and verify you
can choose the notice for claiming
4/ Go on the Claim serials page (serials/claims.pl) and repeat the same
thing with the a "claimissues" notice
5/ Create a new subscription (serials/subscription-add.pl) and verify
you cannot choose a notification for patrons.
6/ Create a notice with module "serial" and verify you can.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script. Additional tests done:
- copy notice ODUE, on saving you are now prompted to choose
a new CODE for the notice
- edit new notice, try to set code back to ODUE. You are
prompted that the code is already in use.
This will prevent people from accidentally overwriting a letter
with the same letter code.
If the template contains dynamic parts, the message won't be
considerated as duplicated.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Duplicate messages will be queued, but when sending the queued messages
duplicates are found and are marked as failed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The previous patch checks if a notice has already been sent when the
current notices has been sent in queue. Which is wrong!
We have to check if a similar notice has been sent today.
This patch has been created after an observation on a production server:
If a user place on holds several items, he will receive 1 SMS per hold.
Here we only want 1 SMS for all holds.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
For PREDUE messages, one message is sent to the message_queue table for
each items in advance, meaning that the patron could receive duplicate
notices.
The SMS part for DUE and PREDUE often do not contain dynamic parts, only
a standard message.
Note that this patch *only* affects the SMS transport.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
GetLetters only returns letters with a mtt = email. It should return all
letter codes in the DB.
The message_transport_type parameter is never used.
To reproduce the issue:
Create a notice with a sms template and no email template.
Go on the overdue rules configucation page.
The notice does not appear in the notice list.
Signed-off-by: Olli-Antti Kivilahti <kivilahtio@ProBook6570b>
---------------
Testing report:
---------------
Testing this subroutine from a test stub. Calling the method without arguments
and with argument 'circulation' and 'circulat'.
Works as supposed to.
Related Bug 11931 discovered but not within the scope of this featureset.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* Fixes POD of GetMessageTransportTypes.
* Removes the useless map in GetMessageTransportTypes.
* Textual: "You must specify a title and a content" ->
"Please specify title and content".
* Reintroduces << and >> around the field name.
* Change message for the update DB entry.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds:
- a new jquery plugin : insertatcaret.
- the ability to define a notice template for each transport type.
- a new routine C4::Letters::GetMessageTransportTypes.
Test plan:
- Go on tools/letter.pl and check that all existing notices are still
there.
- Modify one. A new empty message is present for sms, print, etc. The
email message is filled with the existant value.
- Add a message for sms for example (don't forget the subject) and save.
- edit again and verify the sms message has been saved.
Signed-off-by: Olli-Antti Kivilahti <olli-antti.kivilahti@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan :
- Define a notice containing <<borrowers.streettype>>
- Trigger an event that generate this notice
Without patch <<borrowers.streettype>> is replaced by ROADTYPE
authorised value code. With the patch it is resplaced by its
description
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
This works as described, passes tests and QA script.
Note: it seems it's not possible currently to use B_streettype from
the interface, but it might be worth adding it as a follow up for later
use.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
When you run the Reserves test, you have the warnings:
Use of uninitialized value $branchcode in hash element at /usr/share/koha/testclone/C4/Letters.pm line 138.
Use of uninitialized value $branchcode in hash element at /usr/share/koha/testclone/C4/Letters.pm line 148.
This patch removes that warning.
Test plan:
Run the Reserves.t again.
Revised Test Plan
-----------------
Run the following on the command line prompt before and after
applying the patch:
perl -e "use C4::Letters; *C4::Context::userenv= sub { return {} }; my \$blah=C4::Letters::getletter('circulation','DUE', 'BRA');"
Before the patch there will be errors (as above), after there will not.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
IndependentBranches must be on.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Pasting comment from the Bugzilla report:
Looking bit longer at this code, it is kind of strange to find it
there in the first place. Adding maxpickupdelay in Letters.pm should
not be there, but it is..
Also this date is not used normally in the default HOLD Available for
Pickup notice (that we are generating in this case). And if it would be
undef, the expiration date should imo be empty instead of today+0.
(before adding maxreservespickupdelay, you should test the allowexpire
pref first) So it is an (invisible) bug on its own.
Test plan:
See former patch. Kyle just discovered this bug, apparently by
deleting the maxpickupdelay pref..
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
For DUE message (and PREDUE, etc.) there are no check before sending the
message to the message_queue table.
This check avoids to try to send again and again the same message. Now
it is marked as "failed".
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Without the patch a sms notice will remain as 'pending' forever.
With the patch applied, the status is set to 'failed'.
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test plan:
1) set an empty string for the ReservesMaxPickUpDelay pref
2) place a hold on an item
3) check in the item
4) click on "Print and confirm"
5) an error occurs
> The 'days' parameter (undef) to DateTime::Duration::new was an 'undef'
6) apply the patch
7) repeat steps 1 to 4
8) the error does not occur anymore.
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
An empty string didn't do it for me, I had to set the
variable for the systempreference to NULL. I am not sure
if this can happen when editing from the interface, but
this change should not have any ill side effects and it has
unit tests!
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Koha::DateUtils::output_pref took 4 parameters and the last one is a
boolean, so some calls were:
output_pref($dt, undef, undef, 1)
This patch changes its prototype to
output_pref({
dt => $dt,
dateformat => $dateformat,
timeformat => $timeformat,
dateonly => $boolean
});
An alternative is to call the output_pref routine with a datetime
object, without using an hashref:
output_pref($dt);
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Right now overdues come from the branch, but the
others come from the admin email address - this
is a problem in multi-branch systems because they
have to come up with one email address that all
branches have access to.
C4::Letters::_send_message_by_email currently sets
the from address in the following order:
1) Address specified in message
2) Koha admin email address
The order will now be:
1) Address specified in message
2) Borrower's home library email address
3) Koha admin email address
Test Plan:
1) Set your library email addresses, and the KohaAdminEmailAddress
Make sure each of them are unqiue
2) Choose a borrower, enable the enhanced messaging and enable the
checkout and checkin email notices. Use your email address for
the borrower's email so you can recieve the emails.
3) Check out an item, check the from address of the email,
it should be the email addres set in KohaAdminEmailAddress
4) Apply the patch
5) Return the item, check the from address of the email,
it should match the email address set for the borrower's
home library.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
From-address and to-address were the same (patron's email) for
subscription alerts. This patch changes 'from' the branch or
kohaadminemailaddress
To test
- add a subscription in staff/serials in case you don't have any
- enable patron notifications or the subscription
- in the OPAC, subscribe to the serial
- in staff/serial, receive an issue of the serial
Before applying the patch, the email that is supposed to be sent
has the patron's email as 'from' and 'to' (and is likely to fail).
If you follow the steps after applying the patch, the email alert
should have the 'from' address of the patron's branch or
kohaadminemiladdress -- which should also work fine with the MTA/SMTP
you have set up for messaging.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Generating (e.g.) overdue notices can result in spurious warnings in
the cronjob logs:
$ ./misc/cronjobs/overdue_notices.pl -t -library CPL
prepare_cached(SELECT * FROM issues WHERE itemnumber = ?) statement handle DBI::st=HASH(0x54a7828) still Active at C4/Letters.pm line 589
This patch removes the warning by making sure that the relevant statement
handle is finished after fetching its first row of results.
To test:
[1] Set up an overdue loan such that running overdue_notices.pl will
trigger the generation of a notice.
[2] Run overdue_notices.pl -t and note the warning message.
[3] Apply the patch.
[4] Run overdue_notices.pl -t again and note that the warning message
is no longer displayed.
[5] Check the message_queue table and verify that the overdue
notices generated in steps 2 and 4 have the same text.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The DB field aqorders.biblioitemnumber seems to be unused except to get
the itype on the spent.pl page.
This information can be retrieved uising another SQL join.
Test plan:
Try a complete workflow in the acquisition module: create an order,
receive it, play with the syspref AcqCreateItem.
Check that no regression is found and that the data for existing
orders don't change.
Signed-off-by: Mathieu Saby <mathieu.saby@univ-rennes2.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Test Plan:
1) Enable IndependantBranches
2) Apply this patch
3) Run updatedatabase.pl
4) Verify that the system preference still functions correctly
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Prior to this patch, at more-or-less random intervals pages working
with notices will cease to function. To test:
1) Apply patch.
2) Try to edit some notices.
3) Trigger some notices.
4) If you were able to edit the notices and trigger the notices, sign
off.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
All tests and QA script pass.
I did a regression script without Plack:
- edit, add, delete and copy notice
- trigger checkout/checkin notice
- print issueslip
No problems found.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch makes ParseLetter somewhat more restrictive in removing
punctuation characters from the end of a table field.
Based on the assumption that we want to remove punctuation from fields in
biblio and biblioitems (like ISBD).
ParseLetter should not remove e.g. a parenthesis in itemcallnumber, but still
removes e.g. a colon (:) at the end of a title.
Removed an unneeded global and lookahead from the regex.
Test plan:
1) Add a colon (:) to the end of a title.
2) Add a colon to the end of item copynumber.
3) Place a hold on that item. Check it in. Confirm hold.
4) Check the email or print notice generated. There should be no colon at the
end of the title, but the colon in the copynumber should still be there.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I compared checkout notices with lots of different fields before
and after applying the patch. For example the ) at the end of a
field in branches is now longer removed. Other fields looked ok
before and after.
Passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch modifies Koha::DateUtils::output_pref to support the new system preference TimeFormat, which defines the visual format for a time as either the 24 hour format ( default ), or the 12 hour format (HH:MM AM/PM).
The patch also modifies C4::Members::IssueSlip to use output_pref rather than format_date.
Test Plan:
1) Apply patch
2) Run updatedatabase.pl
3) Issue an item to a patron, verify the times are in 24 hour format.
4) Switch TimeFormat to the 12 hour format.
5) Revisit the patron record you issued an item to, times should now be in a 12 hour format.
6) Print a slip for this patron, you should now see the time as well as the date.
Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests after fixing the test count in t/DateUtils.t.
Fixed conflicts in syspref.sql and updatedatabase.pl.
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
As we have another sign-off on this now I gave it a quick
run through and it works as expected.
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
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>
