At present, if a patron is set to HoldForPickup, checked in Loan requests go to In Transit to Pickup Location and can be moved to Awaiting Customer Contact manually or via routing rule while if a patron is set to MailToAddress checked in Loan requests go directly to Awaiting Customer Contact.

This is fine for the majority of materials, but not ideal for items that are restricted to In Library Use Only (which we will not mail to patrons regardless of their preference) or for items for Blocked patrons (who need to return materials before we'll send items again).

We've had to institute some elaborate work arounds, which are not ideal. Can you either make it so that transactions for MailToAddress patrons don't skip the In Transit to Pickup Location step, or stop requests with these attributes in some other way so we can send the correct type of notice after checking the item in?

Desired behavior: Patrons authenticated via RemoteAuth (EZproxy) who begin but do not complete registration can subsequently return to registration with their data populated from the latest info in the UserValidation table.

We use RemoteAuth for patrons to authenticate via EZproxy, and change implemented in order to preserve user PINs during the ILLiad 9.0 upgrade. We also do a daily upload to the UserValidation table that includes just those patrons who are eligible for ILL service. This table populates the NewAuthRegistration form so they can successfully submit registration and access ILLiad.

When users authenticate via RemoteAuth before they have been added to UserValidation, as there's no data for them in UserValidation yet, the registration form fields are blank (we intentionally prevent users from editing these fields). They cannot submit their registration, but ILLiad creates a User stub account for them with Cleared=New, which sends them back to the registration form each time they login until they've successfully submitted it.. On subsequent login attempts, even after being added to UserValidation, because the User stub account now exists, the registration form instead pulls in data from the blank stub account. Patrons remain stuck, unable to complete registration.

We are advocating for a solution that addresses this blank registration form trap. This may take the form of the Registration form always pulling in data from UserValidation, even if there is a user stub account. Alternatively, all stub accounts with only a username and Cleared=New could be automatically purged, which would force NewAuthRegistration to check UserValidation. There may be other alternatives.

I heard that there will be better SAML support in an upcoming ILLiad release. However, we do not use SAML authentication for our EZproxy setup. Instead we use a combination of CGI and ticket authentication, which passes patrons to our BiblioCommons catalog to login, then BiblioCommons returns a ticket and that essentially provides an SSO experience for our patrons using our catalog and all EZproxy-authenticated resources. So our library would benefit from a solution that also accounts for CGI/ticket authentication in EZproxy.