Support alert/print message for transiting, non-active copies

Bug #1202742 reported by Bill Erickson on 2013-07-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

If a copy is transiting somewhere and the final status of the copy (action.transit_copy.copy_status) is a non-active copy status, show a message in the transit alert dialog and optionally in the printed transit receipt. The idea behind this is that a non-active copy will likely need some type of attention or special sorting once it arrives at its destination.

Code lives at working/user/berick/non-active-transit-copy-status-message

From the commit:

When an in-transit copy is checked into the staff client, display a special message in the transit alert dialog and in the printed transit receipt (optionally, via macro) if the copy is in (or, rather, will be once it arrives at its destination) a non-active copy status.

See config.copy_status.copy_active.

For example, assuming the org unit setting 'circ.lost_immediately_available' is unset, when a Lost copy is checked in that must transit home, the following message will appear in the transit alert dialog:

This item is in status "Lost", additional staff action may be required.

Additionally, the value of the 'transit_copy_status_msg' macro, which defaults to "", will be set to this message, so that the message may appear in printed transit slips.

Note that the code will test for the presence of the "staff.circ.utils.transit.copy_status_message" string property and fail gracefully if it is unset. Through this, admins can disable this feature entirely.

This feature was originally prompted as result of testing bug #1169193

Bill Erickson (berick) wrote :

As it stands, this bug depends on bug #1169193 (I recalled at 2am), because of some other changes that went into that branch to accommodate the transit_copy_status macro. The branch I referenced here (user/berick/non-active-transit-copy-status-message) is a child of the long-overdue branch. If LO is never merged, this work could be factored out as a standalone, master-friendly patch, but I'll cross that bridge if/when necessary.

Ben Shum (bshum) on 2013-07-25
Changed in evergreen:
status: New → Triaged
Remington Steed (rjs7) on 2013-08-12
Changed in evergreen:
milestone: 2.5.0-alpha1 → 2.5.0-alpha2
Dan Wells (dbw2) wrote :

At least part of this doesn't pass my eyeball test:

'render' : function(my) {
    var stat_obj = data.hash.ccs[ my.atc.copy_status()].name();
    if (stat_obj.copy_active() == 't') return '';
    var prop = 'staff.circ.utils.transit.copy_status_message';
    return circStrings.getFormattedString(prop, []);

In particular, the '.name()' in the initial assignment looks wrong, since stat_obj must be the "obj" for the rest of the code to work. Anyway, since I am focusing on review only for today, I am marking this incomplete, but will push a fix branch for the next round if nobody else does.

Changed in evergreen:
status: Triaged → Incomplete
Dan Wells (dbw2) on 2013-08-26
Changed in evergreen:
milestone: 2.5.0-alpha2 → 2.5.0-beta1
Dan Wells (dbw2) on 2013-09-29
Changed in evergreen:
milestone: 2.5.0-beta1 → 2.5.0-rc
Dan Wells (dbw2) on 2013-10-07
Changed in evergreen:
milestone: 2.5.0-rc →
Dan Wells (dbw2) on 2014-02-05
Changed in evergreen:
milestone: 2.6.0-alpha1 → 2.6.0-beta1
assignee: nobody → Dan Wells (dbw2)
Bill Erickson (berick) wrote :

Thanks for the eyes, Dan. Somehow I missed your comment way back when.

I've rebased and fixed the eyeball-offending code. It turns out that chunk of code was not running (like I thought), but only executing if the column is manually added to the transit list display, which I have stopped short of doing (except for testing).

Setting status back to New.

Changed in evergreen:
status: Incomplete → Triaged
Bill Erickson (berick) wrote :

Er, Triaged.

Dan Wells (dbw2) on 2014-02-27
Changed in evergreen:
milestone: 2.6.0-beta1 → 2.6.0-rc1
Changed in evergreen:
milestone: 2.6.0-rc1 →
assignee: Dan Wells (dbw2) → nobody
Kathy Lussier (klussier) wrote :

Hi Bill,

Should we also have a brief release notes entry on this one?


tags: added: needsreleasenote
Bill Erickson (berick) wrote :

Release notes added. Rebased to master.

tags: removed: needsreleasenote
Changed in evergreen:
milestone: → 2.7.0-beta1
Ben Shum (bshum) wrote :

Assigning back to for review during next development cycle.

Changed in evergreen:
milestone: 2.7.0-beta1 →
Chris Sharp (chrissharp123) wrote :

I'm testing this today. So far, I've applied the changes from this branch to our working 2.5.1, but I'm getting the message 'ReferenceError: circStrings is not defined' when I click the "Macros" button with the Transit Slip template in focus. I'm trying to debug this without much success so far.

Chris Sharp (chrissharp123) wrote :

I can confirm that the message correctly appears on the screen and on the transit slip, but the breakage I mentioned in comment #8 is still present.

Chris Sharp (chrissharp123) wrote :

Okay, retested against current master and everything is working as expected.

Signoff branch at;a=shortlog;h=refs/heads/user/csharp/non-active-transit-copy-status-message-signoff.

Changed in evergreen:
status: Triaged → In Progress
milestone: → 2.7.1
Ben Shum (bshum) wrote :

This is still a bit more new feature to me, with the string change and otherwise new functionality. Setting back to a target of to be reviewed during the next development cycle.

Changed in evergreen:
status: In Progress → Confirmed
milestone: 2.7.1 →
Kathy Lussier (klussier) wrote :

Looks like we missed this one in the 2.8 cycle. Adding a signedoff tag so that it gets more attention.

tags: added: signedoff
Bill Erickson (berick) wrote :

Noting for future consideration that this bug will need a browser-client compatible version of this feature.

Kathy Lussier (klussier) wrote :

Finally getting this one into a release. Merged to master for inclusion in 2.10. Thanks Bill and Chris!

Changed in evergreen:
status: Confirmed → Fix Committed
milestone: → 2.10-beta
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers