Web client: Cannot successfully check in hold transit items

After continued testing, I've found that this problem doesn't occur for all holds transit items. When working with the Concerto dataset, it only appears to occur for items that need to fill a hold at SL1. Checking in items that need to transit to other locations to fill holds appears to work as expected.

There's still a problem, but I think we can put the priority down to medium since it isn't affecting all transit holds.

Came across this problem again when checking in a Concerto item required to fill a hold at BM1. So far, it only appears to happen when filling holds at an OU that is a child of a branch.

The message in the console was a little different for this check in:

TypeError: Cannot read property 'id' of undefined
    at env.js:119
    at Object.q [as forEach] (angular.min.js:7)
    at Object.service.absorbList (env.js:119)
    at circ.js:631
    at angular.min.js:132
    at m.$eval (angular.min.js:147)
    at m.$digest (angular.min.js:144)
    at angular.min.js:147
    at f (angular.min.js:45)
    at angular.min.js:48

Confirmed on MLNC's 2.12 test server, and I saw the console error noted by Kathy in comment #2 when I tried with an item to be picked up at SL1 and then her initial error when I tried with an item to be picked up at BM1.

However, noting for the record that I'm not seeing it in EOLI's in-house webby test server which is master-ish with some local code.

I encountered this issue on our own testing server. It consistently happened with holds picked up at one particular library. But holds picked up at the other two libraries in the group sharing almost the same things are fine. It turns out the problematic library did not have Hold Address in the OU record. After filling in the Hold Address, the prompt shows up.

Confirmed that this does seem to fix it for me as well -- although there may be some caching issues, because when I added the address last night, I wasn't able to get the transit prompt to show and still saw the console error in the original bug report. This was even after logging out and a hard refresh.

However, when I came back and tried it this morning, all worked as expected. Thanks, Tina, for the catch!

What should happen when a hold item transits to a branch that has no holds address? Default to mailing_address? What if there's no mailing_address?

The xul client says "We do not have a holds address for this library" in place of where the address normally displays.

Answering your question with a question, but is there a design reason why the lack of an address would cause a failure?

Andrea, just an oversight. The code assumes that holds will transit to branches that have a holds address. That wacky code.

Thanks for checking, Kathy. Seems like a reasonable thing to duplicate in the web staff.

Fix pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1670242-hold-transit-checkin-fix

In addition to the not-dying, this includes changes to the route dialog and transit print templates to display "We do not have a holds address for this library." when no address is present.

To test with concerto, after running the hold targeter, check in item "RDA430001661".

Thank you Bill! It works for me. Merged to master and release 2.12.