I took some time to test the latest branch tonight. I'm very sorry that I didn't test the earlier branch sooner since I know it would have been better to have more time to address issues. I did find a few issues in my testing: 1. I had a couple of problems with checkout alerts. I created a checkout alert owned by the consortium that would display for a normal checkout. - If an item was in transit when the item was being checked out, the item in transit alert boxes would display, and I never saw the alert message that was added to the copy. - If there were some other kind of alert on the for the transaction (patron exceeds max fines, copy needed to fill a hold), a COPY_ALERT_MESSAGE also displayed, but the message says "The requested copy has an alert message attached." In previous testing, the actual alert message showed, I created a screencast showing three instances of checking out the same copy with an alert message. In each case, we saw different behavior on if and how the alert displayed. 2. If I check in a copy that has an alert with a 'next status' and the copy also needs to go into transit or fill a hold, I can't force the new 'next status' to be applied to the copy. Instead, it wants to go into transit or fill the hold. The next copy status should override those actions. 3. If I try to apply the next status in situations where the item doesn't need to go somewhere else, I get the Star Trek warning alert, but the copy does check in with the new status applied. I see the following in the javascript console (I saw similar messages when trying to apply a Discard/Weed and custom Mending status too) angular.min.js:119 TypeError: model.assign is not a function at ui.js:23 at angular.min.js:160 at f (angular.min.js:45) at angular.min.js:48 (anonymous) @ angular.min.js:119 circ.js:1472 Unhandled checkin copy status: 14 : Damaged 4. I'm sure this was an issue in my original testing, but I didn't notice it as a problem until now. The use case is a library checks in another library's item and then applies a temporary alert with a Next Status to send a message to the owning library (DVD needs to be cleaned, for example). The assumption is the owning library is the next one that will check in the item and apply that status. However, items sometimes get misdirected in delivery, and a third library may check in the item. There doesn't seem to be a way to proceed with the checkin without applying that next status. I think we need an option there to not apply a Next Status and proceed with the checkin. 5. Our standard system alerts (I tried Missing, Lost, Lost & Paid) are not appearing at checkin, even when I create an alert type for those events. They do appear at checkout. However, if I added them to Copy Alert Suppression grid, they do not suppress at checkout. I didn't try Claims Returned, Claims Never Checked Out or Damaged. 6. In our earlier testing, we had two Library Settings determining how to handle checkout of Lost or Long Overdue items if those alerts are suppressed. I don't see those settings on my test server, but I may just be staring right at them and not seeing them. Everything else is fairly small (I think) 7. Next status should only be available for alerts that handle check in events. At one time, there was code that disabled the selection of a Next Status in the Copy Alert Types editor for alerts that were identified as check out events. However, this no longer happens. I think that code was added back when we had to identify status by id numbers. Maybe it got missed when we put the nice new select box in allowing users to select statuses by name. 8. The old copy alerts field is in the copy editor and should probably be removed. 9. I came across the issue that I identified in bug 1720878 where the Copy Alerts button in the copy editor was disabled because I had set display fields for the editor. I'm concerned that libraries using the 3.0 web client in production will come across the same issue because the Copy Alert field won't be identified as a display field. Is there any way we can address that problem? Thanks for everything Mike and Galen!