Bug 13498

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?

*** Bug 14885 has been marked as a duplicate of this bug. ***

(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.

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?

(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.

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.

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.

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?

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?

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.

Agreed, thanks Karin. I have reported this to Equinox for comment also.

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';

I took the liberty of making the title of the bug more general to reflect a somewhat wider scope.

(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?

> 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.

Problem still exists on current master. This also happens when printing via "print and clear screen" button.

Tested this a little (sorry if I'm repeating what has already been said). We call printslip.pl when printing ISSUESLIP or ISSUEQSLIP and from there we call IssueSlip(). This then calls GetPreparedLetter(). 
If we add message_transport_type => 'print' parameter to that GetPreparedLetter() call in IssueSlip(), print notice is printed correctly. However if 'print' notice isn't found, GetPreparedLetter() fails to, because

my $mtt         = $params{message_transport_type} || 'email';

obviously has value 'print', not undef and doesn't fall back to email.

So we need to 1) add message_transport_type => 'print' param when calling notices that are primaly printed (not just to printslip.pl but also hold-transfer-slip.pl etc.) 2) determine in GetPreparedLetter() if print notice actually exists and then fall back to email notice.

(In reply to Emmi Takkinen from comment #19)
> Tested this a little (sorry if I'm repeating what has already been said). We
> call printslip.pl when printing ISSUESLIP or ISSUEQSLIP and from there we
> call IssueSlip(). This then calls GetPreparedLetter(). 
> If we add message_transport_type => 'print' parameter to that
> GetPreparedLetter() call in IssueSlip(), print notice is printed correctly.
> However if 'print' notice isn't found, GetPreparedLetter() fails to, because
> 
> my $mtt         = $params{message_transport_type} || 'email';
> 
> obviously has value 'print', not undef and doesn't fall back to email.
> 
> So we need to 1) add message_transport_type => 'print' param when calling
> notices that are primaly printed (not just to printslip.pl but also
> hold-transfer-slip.pl etc.) 2) determine in GetPreparedLetter() if print
> notice actually exists and then fall back to email notice.

Correcting the first point, we need to add message_transport_type to methods which are called when printing mainly 'print' notices. E.g. printslip.pl -> IssueSlip(), hold-transfer-slip.pl -> ReserveSlip().