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

Bug #1833565 reported by Garry Collum
144
This bug affects 31 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned

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.

Garry Collum (gcollum)
tags: added: baskets webstaffclient
Revision history for this message
Janet Schrader (jschrader) wrote :

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.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

Confirming this is still an issue in 3.3.0

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

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.

Revision history for this message
Terran McCanna (tmccanna) 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.

Revision history for this message
Elaine Hardy (ehardy) wrote : Re: [Bug 1833565] Re: Baskets: No Local Call Number in the Print-out or Email

That's good!

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

Georgia Public Library Service

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

(404) 235-7128 | <email address hidden>

(404) 548-4241 | 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
>

Revision history for this message
Kate Coleman (katecoleman) wrote :

+1

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

Lynn Floyd (lfloyd)
Changed in evergreen:
importance: Undecided → High
Revision history for this message
Terran McCanna (tmccanna) wrote :

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

Revision history for this message
Felicia Beaudry (fbeaudry) wrote :

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

tags: added: printing
removed: webstaffclient
Revision history for this message
Terran McCanna (tmccanna) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers