From the CHECKIN and CHECKOUT templates you should be able to access the
following information: item, biblio, biblioitem, patron and library
Test plan:
Define CHECKIN and CHECKOUT notice templates.
You should be able to define them using the TT syntax to produce the
same generated notice messages as with the historical syntax.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
For instance an issue is not fetch from its fk but using the fk
itemnumber.
We need to support them.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On of the awesome things we will be able to do with the TT syntax is the support of plurals.
For instance we will be able to send a list of items, checkouts, etc. to the notice template.
That way we will get rid of our custom syntax like <<items.content>> or <item></item> for instance.
The existing code already has the playground for that but it is not used.
Basically the idea is to add a "loops" key which can contain a list of
object to retrieve from the DB and send to the template.
For instance:
loops => { overdues => [ $itemnumber_1, .., $itemnumber_N ] }
will send a variable "overdues" to the template. It will contain the
Koha::Checkout objects relative to the id passed.
There is one quite big inconvenient to this approach so far: since we
are still supporting the historical syntax, the objects can be fetch by
a script, then the script will send the id to GetPreparedLetter which
will refetch them.
This must be improved, but I suggest to do that later.
Test plan:
prove t/db_dependent/Letters/TemplateToolkit.t
should return green
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Nothing new here since bug 17962, the AR_* notice messages are quite
simple. They send the article_request, patron, biblio, biblioitem, item and
library linked to the article request.
All the fields from these 6 tables should still be accessible using the
TT syntax.
Test plan:
Define TT notice templates for AR_PENDING, AR_PROCESSING, AR_COMPLETED
or AR_CANCELED.
You should manage to create a template to generate the same result as
the historical syntax.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To make ACQ_NOTIF_ON_RECEIV TT compatible, we need to expose data from
the aqorders table. We already have a package for it in the Koha
namespace but it is based on Koha::Object[s].
The other path creates dummy Koha::Tmp::Order[s] packages to make it
usable. Of course we should use a valid Koha::Acquisition::Order[s]
based on Koha::Object, but it's outside the scope of this bug report.
This notice template is quite simple, and it's a good one to start.
From C4::Acq::NotifyOrderUsers, GetPreparedLetter is called with 4
elements: the library, the patron to notify, the biblio and the order
information.
Note that prior to this patch aqorders was filled from GetOrder, which
retrieved a lot of information from the acquisition table (aqbasket,
aqbookseller). The idea with the TT syntax is to access the data from
where it really exists. So if a user wants to display the basket name,
[% order.basket.basketname %] should be used instead.
Note that this will not work at the moment, the basket method is not
defined in the order package.
However the basic template should work as before.
The test added to TemplateToolkit proves that.
Test plan:
Use the default ACQ_NOTIF_ON_RECEIV to notify a patron that an order has
been received.
That generated template should be exactly the same as prior to this
patch.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Currently you can call GetPreparedLetter like:
$prepared_letter = GetPreparedLetter(
(
module => 'test',
letter_code => 'TEST_HOLD',
tables => {
reserves => [ $fk1, $fk2 ],
},
)
);
It assumes that $fk1 is a borrowernumber and $fk2 a biblionumber.
It seems hazardous to do this guess.
I suggest to remove this feature and only allow hashref indeed.
Test plan:
Use different way to generate letters and make sure you do not reach the croak
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
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>
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>
