Many of our patrons need to download their request history to help with their bibliography, at least every six months (due to our data delinking schedule).

In the old pages, this was possible with a simple copy and paste into a spreadsheet program.

In the new 9.1 web pages, there is no easy way to export or print the full list of requests. (Copying and pasting will jumble the format; also, for article requests, key parts of the citation will be missing).

Can you please add a data export option? Thanks! This is very important because we do delink routinely, and users may lose data they need without this ability.

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.