Bug 13498 - 'email' templates used for printing slips
Summary: 'email' templates used for printing slips
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: master
Hardware: All All
: P3 minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 14885 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-12-29 15:17 UTC by Barton Chittenden
Modified: 2020-10-24 16:26 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Barton Chittenden 2014-12-29 15:17:30 UTC
I set up print slips for ISSUESLIP and ISSUEQSLIP using the 'print' template.

When I print from circ/circulation.pl using either "Print Slip" or "Print Quick Slip", I get the text from the the email template.

To reproduce:

Edit the 'email' and 'print' templates for ISSUEQSLIP and ISSUESLIP. Make sure that the email and print templates contain different text.

<koha staff client URL>/cgi-bin/koha/tools/letter.pl?op=add_form&branchcode=&module=circulation&code=ISSUEQSLIP

<koha staff client URL>/cgi-bin/koha/tools/letter.pl?op=add_form&branchcode=&module=circulation&code=ISSUESLIP

Check out items to a test patron.

On the check-out page, select Print->Print Slip. Print the slip. Do the same for 'Print quick slip'.

Note that the text from the 'email' template is used.

When resolving this bug, a bit of thought is going to be required, because 'Print' is the primary use of this slip, so it should come first in the list, but we don't want to create a slap-dash one-off of the print slip template page just to accommodate that.
Comment 1 Katrin Fischer 2014-12-29 15:22:05 UTC
I think the slips are different to the other notices, as they can only be printed and are not made to be used with other transport options. Maybe it would be worth hiding the other options in this case and only offer print?
Comment 2 Barton Chittenden 2016-10-05 15:41:26 UTC
*** Bug 14885 has been marked as a duplicate of this bug. ***
Comment 3 Barton Chittenden 2016-10-05 15:44:29 UTC
(In reply to Barton Chittenden from comment #2)
> *** Bug 14885 has been marked as a duplicate of this bug. ***

I've marked bug 14885 as a duplicate, but we should note that there are other slips affected -- RESERVESLIP comes to mind.
Comment 4 Barton Chittenden 2016-10-05 16:02:24 UTC
If we use the message transport type 'print', I believe that we may risk having the slips processed by gather_print_notices.pl.

Perhaps we should introduce a message_transport_type of 'slip' for these?
Comment 5 Katrin Fischer 2016-10-16 12:38:30 UTC
(In reply to Barton Chittenden from comment #4)
> If we use the message transport type 'print', I believe that we may risk
> having the slips processed by gather_print_notices.pl.
> 
> Perhaps we should introduce a message_transport_type of 'slip' for these?

The slips don't go through the message_queue, so print should work ok, I think.
Comment 6 Barton Chittenden 2016-12-09 00:16:18 UTC
I'm raising the priority on this -- I'm getting more support tickets about this, primarily from libraries who have come to Koha since we aggregated the notice templates in 3.16 -- when we made the switch, using the 'email' template was logical, because they're always at the top, and at the time there was no way to collapse the templates, so it would have seemed to users that their slips had 'disappeared' if they weren't at the top of the list... but now, since users have to click on the template that they want to edit in order to expand the template for editing, choosing 'print' is now the logical choice, and users are confused when the edits that they've made to the print template don't appear.
Comment 7 Agnes Rivers-Moore 2017-01-17 21:22:52 UTC
I ran into this. Modify Notice - edit for slips has nothing at all in the 'print' tab but does have the content in the 'email' tab.
That is very confusing - and as Barton said, adding to the 'print' tab seems to have no effect.
Also I notice that after making changes to the layout in the 'email' tab, and then attempting to print the slip - changes are not there in the print for some time and the preceding versions continue to appear fairly randomly.
I tried closing browser, using a different browser... and still I would get the version before last or the one before that instead of the most recently submitted for 20 minutes or more after making changes.
Comment 8 Katrin Fischer 2017-01-17 21:40:26 UTC
Hi Agnes, I have seen something similar on 3.22 - could you open this as a separate bug report with the Koha version you are using? Are you using caching and/or Plack?
Comment 9 Agnes Rivers-Moore 2017-01-18 00:55:34 UTC
Hi Katrin
Version 3.22.07. Yes, using Plack I believe. Galen could tell you more- we're hosted & supported by Equinox.
Which part should I submit a new bug for - the very slow or failed updates to notice templates?
Comment 10 Katrin Fischer 2017-01-18 01:40:45 UTC
Hi Agnes, we have seen problems with changes not taking effect for a while on 3.22.8 - I am not sure yet if it is to be expected or a problem with how Plack/caching works. As 3.22 is very old now, it would be good to confirm the behaviour in newer versions first.
Comment 11 Agnes Rivers-Moore 2017-01-18 01:56:22 UTC
Agreed, thanks Karin. I have reported this to Equinox for comment also.
Comment 12 Magnus Enger 2018-02-27 11:05:24 UTC
This is also a problem when you return a book and click on "Print slip and confirm": the email version of HOLD_SLIP is printed, not the print one. 

Contrary to what Katrin says in Comment 5, it looks like the email version is both displayed in the popup for printing *and* added to the message_queue. The messages show as "print" and "pending" on the patron account of the patron that has the hold on the book. 

In this case the print popup displays circ/hold-transfer-slip.pl, which calls C4::Reserves::ReserveSlip():

  54 if ( my $letter = ReserveSlip ($session->param('branch') || $userenv->{branch}, $borrowernumber, $biblionumber) ) {
  55     $slip = $letter->{content};
  56     $is_html = $letter->{is_html};
  57 }

ReserveSlip() calls C4::Letters::GetPreparedLetter without a message_transport_type parameter:

1886     return  C4::Letters::GetPreparedLetter (
1887         module => 'circulation',
1888         letter_code => 'HOLD_SLIP',
1889         branchcode => $branch,
1890         lang => $patron->lang,
1891         tables => {
1892             'reserves'    => $reserve,
1893             'branches'    => $reserve->{branchcode},
1894             'borrowers'   => $reserve->{borrowernumber},
1895             'biblio'      => $reserve->{biblionumber},
1896             'biblioitems' => $reserve->{biblionumber},
1897             'items'       => $reserve->{itemnumber},
1898         },
1899     );

And C4::Letters::GetPreparedLetter() assumes email for the missing message_transport_type parameter: 

 694     my $mtt         = $params{message_transport_type} || 'email';
Comment 13 Magnus Enger 2018-02-27 11:09:08 UTC
I took the liberty of making the title of the bug more general to reflect a somewhat wider scope.
Comment 16 Barton Chittenden 2019-02-05 17:56:59 UTC
(In reply to Magnus Enger from comment #13)
> I took the liberty of making the title of the bug more general to reflect a
> somewhat wider scope.

The following Slips do not have message_transport_type defined and therefore will
use the default 'email' mtt:

HOLD_SLIP
ISSUEQSLIP
ISSUESLIP
TRANSFERSLIP
SR_SLIP

These are already set as 'print':

OVERDUES_SLIP
AR_SLIP

Could we perhaps set HOLD_SLIP, ISSUEQSLIP, ISSUESLIP, TRANSFERSLIP and SR_SLIP to use the 'print' message transport type, but fall back to 'email' if that doesn't exist?
Comment 17 Katrin Fischer 2019-02-06 06:07:58 UTC
> Could we perhaps set HOLD_SLIP, ISSUEQSLIP, ISSUESLIP, TRANSFERSLIP and
> SR_SLIP to use the 'print' message transport type, but fall back to 'email'
> if that doesn't exist?

Sounds like a good solution to me. I believe there is a fallback the other way around for the other notices even? 

We could probably also just fix it with SQL, but I am not sure how confusing it might be for the libraries wanting to change something after update.