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.

It would be great to be able to send an e-mail notification (from a template) to an individual user, lender, or borrower from the user record, or address record for a library. One instance I would use this for would be to provide individualized tracking information that may apply to a large number of requests at one time. Or to alert a patron of an entire list of things they have out--or to let a group of patrons know that we are temporarily suspending a particular aspect of service. Although many of these things could be handled through a regular e-mail client, it is very helpful to have the tracking within Illiad of what information has been sent. Additionally, it would be helpful to be able to send using a template that we already have right in the client.

OCLC Lending requests remain in processing queues even when they have aged out and moved to the next lender (or are returned to the borrowing library unfilled, if the library is the last/only in the lending string). Staff are unable to filter by or see the OCLC status in grid views, so individual requests must be opened to see if a request is no longer in a CONSIDERING status and has aged (or even been deleted by or cancelled by the borrower). Requests may age out for various reasons while sites are continuing to retrieve/process requested items and it is easy to miss the OCLC status while moving through repetitive tasks and accidentally mark the item as Shipped, even though the request is no longer active for the lending library. This creates a great many problems, including lost money for both institutions (postage and/or replacement fees) and has often created a situation where the next lender marks the item as shipped, but the previous lender has already mailed the item (after accidentally marking an aged request as shipped) and then the borrowing library accidentally checks in the first lender's item as if it had been provided by the second lender. Then the second item mysteriously appears, accompanied by correct documentation, and the first copy is with a patron. Now the borrowing library must pay for postage to mail back two items and it wastes lots of staff time tracking down copies. Please create an immediate error if staff clicks a button that would update the item's status to Shipped -ie Mark Found, Mark Found Scan Now...(or better yet, automatically move these requests to an equivalent of Borrowing's "Unfilled" queue, so staff don't even have to waste time accidentally getting to a place where they could click Mark Found!) The Connection Manager error is easy to miss and, often, too late. -written up by Kerry, as per customer request, which was placed by SUNY Shared Library Services, on behalf of multiple SUNY ILL professionals. (#16610)