Hold Shelf Print Full List Fields Are Hard Coded

[Ryan Eby]

Still current as of master in Evergreen git.

Related bug: https://bugs.launchpad.net/evergreen/+bug/1838553

The Circulation > Hold Shelf interface has two options to print the list. The Actions > Print Full Grid prints the grid as staff have it.

In relation to bug #1838553 we have patched our install so preferred names show up for the various patron name fields they can choose.

However, the Print Full List button uses a hardcoded function that has specific fields regardless of what staff setup. This function does not use the preferred name at all.

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/staff/circ/holds/app.js;hb=b5eb3fe1d3a23b8670bb13ba523845bb04f20cb6#l289

I'm not sure if it would be better for this button to act the same as the Print Grid of if it could be modified to allow customization of fields to print. Our main need is having the preferred name in the list but we will have staff use the grid print in the meantime.

[Ryan Eby (aadl-ubuntu)]

This bug is for the Hold Shelf interface where you clear holds and see what items are on the hold shelf. Not the hold pull list.

The interface located at /eg/staff/circ/holds/shelf

It uses the template t_hold_shelf_list.tt2 but that template is populated with hard-coded data from the app.js

[Jessica Woolford (jwoolford)]

Sorry about that! I should refrain from commenting on bugs at the end of a long day. :)

I deleted my comment and confirmed the bug.

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

Hello, we just ran into this on 3.11.1

Trying to create a list of items on the holdshelf that matches what we use for our hold slips.

We create a short name for holds using the first 4 letters of last name, first letter of first name and last two digits of barcode.

We make use of the preferred name fields if they are set.

<div style="font-size: 33pt; font-weight: bold; width: 20px; margin-left: -20px; margin-top: 21px; overflow-wrap: break-word; text-transform: uppercase; transform:rotate(270deg);transform-origin:top right; line-height:.9em; text-align: left">
{{patron.pref_family_name ? patron.pref_family_name : patron.family_name | limitTo:4}}{{patron.pref_first_given_name ? patron.pref_first_given_name : patron.first_given_name | limitTo:1}}{{patron.card.barcode | limitTo:2:-2}}
</div>

We would like to have a hold shelf print template to print out those identifiers for double checking the hold shelf.

But the preferred name info doesn't exist for the hold shelf print template.
Josh

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

3.11

I've been looking into this again and realized a few things.

Part 1 of this issue - access to preferred name components.

wide_hold_data doesn't include the preferred name fields broken out individually. It is straightforward to add them, but I'm wondering if we really need to provide the non preferred fields in addition to the legal name fields for wide holds. In all our uses of the wide hold data, we just want to be able to referrer to the patron how they want to be addressed. I cannot think of a reason why we need the non preferred/legal name components. But maybe others have need for both to be available?

Bug 1838553 and bug 1996651 updated the user display name and "user display name or alias" to show the preferred data in one string that combines all the various parts.

But if you need just individual parts of the patrons name then you don't have access to the preferred name fields.

So maybe part of the solution might be to change the legal name fields so the preferred name is shown by default if it exists?

Part 2 of this issue - hardcoded fields for print template generation.

I'm assuming that the reason for hard coding those fields was to make the variable names more intuitive for the print templates... And to allow the preview to work in the print template editor with the supplied test data format.

All the grid data is available to the template due to it being accessible via the .hold key. But it uses the fields names from wide_hold_data which are not user friendly. Some of the fields are also pulled out based on the prefix, like copy, volume and part data under the .copy, .volume and .part keys.

So from the default hold shelf list template, these variables are equivalent and either can be used.

{{hold_data.title}} = {{hold_data.hold.title}}
{{hold_data.patron_last}} = {{hold_data.hold.usr_family_name}}
{{hold_data.copy.barcode}} = {{hold_data.hold.cp_barcode}}

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/templates/staff/share/print_templates/t_hold_shelf_list.tt2;hb=HEAD

Here is a list of the fields that I have on my test system. (I have some extras that I'm playing around with, like adding the preferred name fields to test that out, so this won't match your system.)
https://gitlab.com/LARL/evergreen-larl/-/snippets/3721032

I'm not sure what the best way to document all those fields would be... but I think that the data is there once it shows up in the grid.
Josh

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

Here are a couple of working branches that add the preferred data in two ways to wide_hold_data

First - use the preferred data by default.
user/stompro/lp1968750_wide_holds_preferred_name_fields_default
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1968750_wide_holds_preferred_name_fields_default

Second - Add in a set of fields for the preferred name data.
user/stompro/lp1968750_wide_holds_preferred_name_fields_duplicated
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1968750_wide_holds_preferred_name_fields_duplicated

I prefer the first one, since it is simpler, but maybe someone needs to access the non-preferred name fields in the pull list and hold shelf?

I think either one would solve is issue of not being able to access preferred name fields in the hold shelf list print template.