Wishlist: Make Call Number SMS aware of item details

Bug #1917789 reported by Jennifer Bruch
48
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

Observed in When a patron uses the Send Call Number to phone option, it can send confusing or incorrect item location information.

Example: Item has differing owning and circ library settings. This can happen in consolidated library situations where all titles are owned by the main branch and they circulate out of various others. Also, happens with floating/rotating collections that are shared from owning library and circulate for a few months from a partner library.

The SMS link is next to each call number in a list of items, not just a single distinct instance of each call number. This implies that it should be aware of each distinct copy.

Especially, if a patron sends the info for a copy that is available vs one that is checked out.

It would be nice if the trigger was aware enough of the item to see the Circ Library.

Could be related to 1833565 and 1749475 and 1510595

Revision history for this message
Brandt Ensor (baensor) wrote :

Yes, our library system is consolidated and this happens to us. We would love to have this fixed.

tags: added: actiontrigger
Revision history for this message
Terran McCanna (tmccanna) wrote :

I haven't tested this, but it looks like this might just be a matter of modifying your SMS Call Number message in Administration > Local Administration > Notification / Action Triggers.

For example, for library name, I believe you'd change [% target.owning_lib.name %] to [% target.circ_lib.name %]

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Hello, I ran into this a few weeks ago when using this feature and had looked into this. I expected to get info for the specific copy that I selected... but that wasn't the case.

The default action trigger definition makes use of the acn.format.sms_text hook, which uses asset.call_number as its base class. So there is no item info included. [1]

But the link for the send sms seems to include copy info.
https://egcatalog.larl.org/eg/opac/sms_cn?copy_id=3530427;rec=382199

There is a helper function - helpers.get_most_populous_location( target.id ).name [2]
The comments say "# given a call number, returns the copy location with the most copies" So that comes up with the copy shelving location that has the most copies... for the specific acn passed.

I don't think Terran's suggestion will work because the target is the acn, which only has an owning_lib. The copy has the circ lib info.

It seems to me that the hook should be changed so the target is the specific copy instead of the call number, so the circ lib info is available, and the exact shelving location can also be used.

I think the SMS.pm [3] also needs to be changed or extended.

I'm trying to think of a reason why the current behavior would need to be kept and a library setting needed to switch between two modes. It seems like a copy based version of this would cover the bases, without needing to guess about the copy shelving location.

1 - https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql;hb=5b7187ce79dd13cc567d6dee5c46554333b9b5e1#l15372

2 - https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Trigger/Reactor.pm;hb=5b7187ce79dd13cc567d6dee5c46554333b9b5e1#l143

3 - https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/SMS.pm;hb=5b7187ce79dd13cc567d6dee5c46554333b9b5e1

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.