Patrons are people who need to use resources. Technically, every person who uses WebCheckout is a "patron", including the operators who run the resource checkout centers. However, the term is primarily used to refer to the people who need to use the resources that are managed with WebCheckout. They belong to the institution where WebCheckout is installed, and may include faculty, staff, graduate and undergraduate students, etc.
For more information about WebCheckout operators, see Chapter 11, Operators.
This chapter describes patrons, patron classes, how to add new patrons, how to find patron information, and how to manage patron accounts.
Each patron in WebCheckout belongs to a patron class. Patron classes are categories for organizing patrons in WebCheckout that match their academic or employment status in the school, i.e., faculty, staff, graduate students, undergraduates, etc. Patron classes are used with circulation policies to determine which policy settings to apply during a transaction.
For more information about circulation policies and patron classes, see Section 1.5, “Understanding circulation policies”.
There are ten patron class categories in all. They are arranged in a hierarchy with faculty at the top and the default, , at the bottom.
- Faculty
Can include tenured faculty only, or all instructors regardless of their tenure status, depending on the needs of your own organization.
- Employee
Institution employees, inclucing WebCheckout operators.
- Grad2
Upper-level graduate students.
- Grad1
Lower-level graduate students.
- Undergraduate-senior
Undergraduate student in their fourth year.
- Undergraduate-junior
Undergraduate student in their third year.
- Undergraduate-sophomore
Undergraduate student in their second year.
- Undergraduate-freshman
Undergraduate student in their first year.
- Continuing education
Continuing education students.
- Other
This is the default patron class. All patrons are initially given this class designation, and all circulation policies (resource type, checkout center, and organization) are set to be applied to the class by default. Some of this behavior is described below:
If a patron's class has been left as , then the circulation policies for are applied during the patron's circulation transaction.
If a patron's class has been changed to something besides , but the circulation policies have not, then the circulation policies for are applied during the patron's circulation transaction.
If a patron's class has been changed to something besides , and circulation policies have also been set for that same patron class, then those policies are applied during the circulation transaction. For example, if you want certain patrons, such as faculty, to have different borrowing privileges from other patrons, then you must set the faculty member's patron class to , and create a set of circulation policies for patrons.
If circulation policies have been set for only one type of patron class, such as , then patrons with a higher class level, such as , will fall through to the Grad1 policies. Patrons with a lower class level, such as will be subject to the policies for .
Who can do this
Operators with the Manage people capability.
Everyone who uses WebCheckout has to be added as a patron first, including those who are being added as operators.
Procedure 7.1. To add a patron
Click the
banner icon to open the Find People screen.
In the left frame, click the Add a person link, which opens the New Person Wizard.
Complete each step in the Wizard.
Wizard Step 1
Enter a unique ID number and the patron's name. Assign the patron class, select the organization the person is associated with, and enter their department. Click .
Wizard Step 2
Enter the new patron's contact information, and click .
Wizard Step 3
Check over the patron's information and go back and make corrections if you need to. Click to confirm the new person. The screen refreshes and the new patron is now entered in WebCheckout.
Now that the patron is added, you can go on to other tasks or do one of the following:
Click the User ID link to open the Person Detail screen where you can make changes or enter additional information if necessary.
Add another person. Just click the Add another person link and go through the Wizard again.
Add this patron as an operator.
This topic describes how to find information about a patron.
This is the first step for many WebCheckout tasks, such as editing local patron contact information, adding notes to patron records, viewing checkout activity, looking up fines, etc.
Who can do this
All operators.
Procedure 7.2. To view information about a patron
Click the
icon on the to open the Find People screen.
Search for a patron by entering their ID or their name (first and/or last) into the Find fields. You don't need to enter both.
Unless you select the Match full names only option, you can search on partial names.
Click the button.
Search results are displayed in the right frame.
Click on the patron's UserID link to open the Person Detail screen.
This screen displays contact and other basic information about this patron. Information about fines is stored on the Invoices tab.
Click on the other tabs to view additional information about this patron, including fines, authorizations, editable contact information, checkout and reservation activity, and what groups (if any) they belong to.
Procedure 7.3. To find patron information using reports
You can also use several reports (i.e., pre-set "Find" screens) to find specific types of patron information, including oustanding invoices, holds, overdues, etc.
Click the
banner icon to open the Available Reports screen.
Click on a link to open a report.
Enter your search criteria and run the report.
For more information about using the search screens, see Section 14.2, “Find Screens”.
One of the newest features added to WebCheckout is the email messaging module. Documentation for this module is not yet available. However, this draft provides temporary help for users who need to work with this feature until the documentation can be developed.
* Emailable Situations A means is provided on the
interface to send email to patrons in the following situations: -
After reservation has been created, send the patron email
notifying that the reservation was made, including details,
especially set/strike/show information.
Confirm Reservation screen - Pending
reservation, send the patron an email reminder of the upcoming
reservation. Reservation Detail screen -
Reservation affected by resource taken offline; contents of the
email will vary depending on whether the resource was replaced or
not (see bug 1888). - Checkout reminder emailed to patron to
remind them of a pending return time.
Returning checkout -
Late checkouts reminder sent to patron when they have overdue
resources.
Returning checkout - Fines notice emailed to
patron as a reminder that they are accumulating charges.
Invoice - Class or group authorizations
expiration notice sent to patrons.
Class Detail,
Group
Detail Emails are sent to the patron(s)
affected. For allocations, if there are pickup people associated
with an allocation, those patrons are also CC'd on the
email. * Ad Hoc Email A link is provided on the patron detail
screen which contains a "mailto" link. This allows the
operator to manually initiate an email to the patron covering
whatever topic the operator wants. It's purely a convenience
measure. No email contents are or can be filled out. This
functionality requires that the browser is configured or
associated with a valid mail system. * Using Email To Help
Collections Fine collections is a particular issue where email
can be helpful. However, going to each fine individually and
emailing them can be rather inconvenient when there are
significant numbers of fines. To assist with this, the find fines
screen is expanded to allow the patron to indicate that email
should be sent to the patron regarding the fine from the list of
results (rather than from the detail screen). "Select
all" and "deselect all" is also provided. After
the appropriate checkboxes have been selected, an email is sent
to the indicated patrons, grouping multiple fines for a single
patron in one email. The results screen is again returned, with
all checkboxes unchecked. * Email Logging Emails regarding
allocations and fines will be logged against the allocation and
the fine itself, so that the operator may see the history of
reminders that have been sent. (Note that emails are logged even
for the bulk fine mailing above.) * Employee Email Authorization
Not all operators are allowed to send emails automatically.
Instead, there is a new capability, "Email patrons",
which can be assigned to operators. As such, sending emails are
PIN events. Question: which role should include this capability?
* Patron Email Suppression New setting is provided on the patron,
"Don't send email". If this setting is on, no
emails are produced to this patron. * Email Templates The content
of email is defined by ASCII templates, which are configured as
files on the server. These files have special "out of
band" characters where substitutions are made, filling in
the appropriate information. Different organizations have
different sets of templates. The following templates exist,
corresponding to the situations detailed above: - reservation
detail (for reservation created or reservation reminder) -
reservation affected by resource going offline (e.g., more
generally, your reservation was changed) - checkout reminder -
late checkout reminder - fine reminder - authorization expired
Templates should probably be provided by the institution's
administrator and put in place by onShore Development.
Alternatively, the customer can edit the templates in place,
assuming they have basic Unix competency. Ultimately the
templates should be editable in the interface, as the
administrator.