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

[Bill Erickson]

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)]

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.

[Dan Wells (dbw2)]

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, [stat_obj.name()]);
}

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.

[Bill Erickson (berick)]

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.

[Bill Erickson (berick)]

Er, Triaged.

[Kathy Lussier (klussier)]

Hi Bill,

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

Kathy

[Bill Erickson (berick)]

Release notes added. Rebased to master.

[Ben Shum (bshum)]

Assigning back to 2.next for review during next development cycle.

[Chris Sharp (chrissharp123)]

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)]

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)]

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

Signoff branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/non-active-transit-copy-status-message-signoff.

[Ben Shum (bshum)]

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

[Kathy Lussier (klussier)]

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

[Bill Erickson (berick)]

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

[Kathy Lussier (klussier)]

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