Holds for Patron should allow to print user name and barcode

[Erica Rohlfs]

version 3.6.2

Administration > Workstation > Print Templates > from the Template Name dropdown, select Holds for Patron.

When adding <div>Name: {{patron.first_given_name}} {{patron.family_name}}</div>
<div>Barcode: {{patron.card.barcode}}</div>, the information displays in the template preview.

Save the template.

Retrieve a patron account, view their holds, and click the Print button underneath their holds, the "Name:" and "Barcode:" text displays but the patrons actual name and barcode information is not present.

The actual print should reflect the template display.

[Jason Etheridge (phasefx)]

Thanks Erica!

Branch pushed to collab/phasefx/lp1926971-print-holds-for-patron

Here's a template that exercises the bug/change:

<div>
<div><strong>Welcome to {{current_location.name}} Public Library!</strong></div>
<div>Name: {{patron.first_given_name}} {{patron.family_name}}</div>
<div>Barcode: {{patron.card.barcode}}</div>
 <div>You have the following title on hold:</div>
 <hr/>
 <ol>
   <li ng-repeat="hold in holds">
     <div>{{hold.title}}</div>
   </li>
 </ol>
 <hr/>
 <div>{{current_location.shortname}} {{today | date:$root.egDateAndTimeFormat}}</div>
 <div>You were helped by {{staff.first_given_name}}</div>
<br/>

[Josh Stompro (u-launchpad-stompro-org)]

Tested this on Terran's test server 1 and it worked as described. I added the patron info fields to the holds for patron template. Then picked a patron with holds and printed their list, and the patron's name and barcode show up.

signoff branch on the way.

Josh

[Josh Stompro (u-launchpad-stompro-org)]

Signoff working branch at user/stompro/lp1926971-print-holds-for-patron-signoff

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1926971-print-holds-for-patron-signoff

Josh

[Galen Charlton (gmc)]

Pushed to master, rel_3_7, and rel_3_6, along with a follow-up to have the default holds-for-patron print template document more of the fields at are available to it.

This straddled the line between a small enhancement and a bugfix, but I ended up treating it as a bugfix.

Thanks, Erica, Jason, and Josh!