Baskets: No Local Call Number in the Print-out or Email

[Garry Collum]

When viewing a basket the screen displays a local call number. If you use the print or email option for this basket the local call number is not present in the print-out or email. The expected behavior is that the local call number would also be in the print-out.

[Janet Schrader (jschrader)]

CWMARS can confirm this in release 3.2.4 I can also confirm that in our consortium if the search is scoped and the local library's item is not available then the system displays the call number of the next available item instead of the local call number.

[Jennifer Pringle (jpringle-u)]

Confirming this is still an issue in 3.3.0

[Jeff Davis (jdavis-sitka)]

The correct way to determine the local call number is to look at the context when a title is added to a bucket, and select a call number based on holdings for that title at some combination of preferred library, search library, physical_loc, and home library (more on this below).

Unfortunately none of that context is available to the action trigger for print/email. Baskets are anonymous lists. They don't exist in the database, they are just a list of record IDs that gets stored in memcached. Currently there's no provision for storing other information (either context org or actual call number) alongside the record IDs.

For email, we could use the user's home library to look up a local call number when the trigger is being processed. This would be a quick shortcut, but it won't be correct in all cases (e.g. if I'm a BR1 patron, but I was searching at BR2 and want to take my list to BR2 to grab the titles off the shelf). For print, we don't even have that option since the action trigger doesn't know anything about the user.

I think we would need to rework anonymous lists so that they support a local call number for each record. The call number should be determined when the title is added to the list so that it can be based on the user's current context.

As noted above, the currently-displayed local call number is not always correct. I think the best way to determine the local call number is like this:

1. Start at the search library or physical_loc, whichever is narrower.
2. Look for holdings at this scope. When there are multiple holdings to choose from, priority for selecting the call number should be based on (1) preferred library, (2) home library, and (3) status of copies (preferring call numbers for copies that are available and can circulate).
3. If no holdings are found, broaden your scope and reiterate from step 2.
4. If you have gone through your entire search library/physical_loc scope (whichever is broader) and haven't found any holdings, there is no local call number, so don't display one.

The same algorithm should be used for displaying the local call number in the OPAC and for print/email. It's complicated, but I think anything simpler will produce incorrect results for some use cases.

[Terran McCanna (tmccanna)]

It may be useful to look at: https://bugs.launchpad.net/evergreen/+bug/1749475

Once the bugs are smoothed out of that project, then it would resolve this printing issue amongst others.

[Elaine Hardy (ehardy)]

That's good!

J. Elaine Hardy, PINES and Collaborative Projects Manager
------------------------------

Georgia Public Library Service

2872 Woodcock Blvd., Suite 250 | Atlanta, GA 30341

[phone] | <email address hidden>

[phone] | Cell

<https://www.facebook.com/georgialibraries>
<https://www.twitter.com/georgialibs>

Join our email list <http://georgialibraries.org/subscription> for stories
of Georgia libraries making an impact in our communities.

On Fri, Sep 13, 2019 at 3:31 PM Terran McCanna <
<email address hidden>> wrote:

> It may be useful to look at:
> https://bugs.launchpad.net/evergreen/+bug/1749475
>
> Once the bugs are smoothed out of that project, then it would resolve
> this printing issue amongst others.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: <email address hidden>
> https://bugs.launchpad.net/bugs/1833565
>
> Title:
> Baskets: No Local Call Number in the Print-out or Email
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> When viewing a basket the screen displays a local call number. If you
> use the print or email option for this basket the local call number is
> not present in the print-out or email. The expected behavior is that
> the local call number would also be in the print-out.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1833565/+subscriptions
>

[Kate Coleman (katecoleman)]

+1

Looks like the adjacent bug is being released in Beta, so we're looking forward to this issue being resolved as well.

[Terran McCanna (tmccanna)]

Updating this to say that the improved email & printing work at https://bugs.launchpad.net/evergreen/+bug/1749475 has been committed to 3.6.

[Felicia Beaudry (fbeaudry)]

Confirming that call number is still not printing from baskets in the staff interface.

[Terran McCanna (tmccanna)]

Noting that as of 3.6 the new print functionality works in the OPAC and there is a separate bug to add it to the new Angular Staff Catalog:

https://bugs.launchpad.net/evergreen/+bug/1899408

[Terran McCanna (tmccanna)]

Closing this ticket as per comment #9