The purpose of a hold is to ultimately get an item to a user. There are different "levels" or types of hold requests: title, volume (and now "Issuance"), item, and "meta-record". By default, the public catalog accessible to patrons only offers title level holds (and meta-record holds), while the staff catalog offers all hold types (currently no interface for Issuance holds). Ignoring for a moment any library specified hold rules (or exceptions, permissibility checks, etc.), title level holds can be fulfilled with any item attached to a volume on the specific bib record for the title being targeted. Volume level holds can be fulfilled only with items attached to the specified volume (library+call number combination) being targeted. Item level holds can only be fulfilled with the specific barcoded item being targeted. A meta-record hold is used if the user uses the Advanced Hold Options for alternate formats when placing the hold; an item belonging to any record from within a group of records (multiple formats and editions for the same "conceptual" title, similar to what you can do with FRBR) can be used to fulfill the hold, subject to any format restrictions selected and a language restriction based on the language of the title that was used as the entry-point for placing the hold.

As a hold is placed, a hold targeter will try to find an available item to list on a library's Pull List for Hold Requests. The first place it looks is at the hold's pickup location. If no eligible items are available at that location, then it'll work its way up the organization hierarchy, one layer at a time (disclaimer for developers: this is a simplistic view, we're really dealing with distances between nodes in the org tree). For example, if a consortium has their hierarchy modeled such that you have Consortium (no volumes allowed) -> System (no volumes allowed) -> Branch (volumes allowed) -> Sub-Library (volumes allowed), and the pickup location is of the type Sub-Library, then if there are no available items, the targeter will look at the immediate parent organization, which will be a Branch. If the Branch has no eligible items available, then it'll consider all of its descendants, the sibling Sub-Libs to the Pickup Sub-Lib. If we still haven't found an item to target, then we'll reach up to the System. In our hypothetical example, we have the System org-type defined as not allowing volumes (and thus no items), so the targeter will not find any there, and will move on to the System's descendants (all of the branches and sub-libs underneath it). If we still haven't found an item to target, the targeter will reach to the top-level, and check all of its descendants (every location possible).

http://www.gliffy.com/pubdoc/1270281/L.jpg

Items are captured for holds using either the Check In interface or the Hold Capture interface (which is just a variant on the Check In interface). Evergreen does "opportunistic" hold captures for eligible items, depending on the type of hold, regardless of which item is currently targeted. One feature in development is the suppression of opportunistic hold captures for a set duration, except at the pickup location.

Items that are captured at a location other than the pickup location are sent to the pickup location. Add details.

After items are captured and transferred to the pickup location they are placed on the hold shelf where they remain until the customer picks them up, they expire from the holdshelf, the hold is canceled, … (what other conditions could cause holds to be removed from holdshelf).

After an item is placed on the holdshelf customers are notified that they have items that they need to come in and check out. Telephone and email notification are hard coded into the hold record. Email notification is handled automatically by the system. Telephone notification is handled manually by staff by calling based on the information in the hold slip. Staff can add an entry to the system to record that a phone call or other notification method was attempted.

This class/object/table describes/stores hold requests. The fields are:

fieldname	description
bib_rec *	A virtual field pointing to the bibliographic record for the hold
cancel_time	If the hold is cancelled, this will be set to a date/timestamp
capture_time	If an item has been captured for the hold, this will be set to a date/timestamp
current_copy	If an item has been targeted or captured ( is this correct?) for the hold, this will be set to its internal ID
eligible_copies *	This references the items that could potentially satisfy the hold ( when does this get set and who uses it? Is it an array of ID's?)
email_notify	This is either true or false, and determines whether an email notification will be sent to the patron (usr) when the status for the captured item becomes On Holds Shelf
expire_time	( is this implemented?) If set, the hold will expire at this time
frozen	( is this implemented? can it be true if a target is captured?) If set to true, then nothing will act on this hold
fulfillment_lib
fulfillment_staff
fulfillment_time
hold_type
holdable_formats
id
ischanged *
isdeleted *
isnew *
notifications *
notify_count *
notify_time *
phone_notify
pickup_lib
prev_check_time
request_lib
request_time
requestor
selection_depth
selection_ou
status *
target
transit *
usr

Entry points for hold placement:

• the public catalog (when authenticated)
  • on a Record Summary page
  • each entry on a My Title Results page
• the staff catalog
  • on a Record Summary page
    • in the upper right for a title level hold
    • next to a volume for a volume level hold
    • next to an item for an item level hold
  • each entry on a My Title Results page
• future: the Item Status interface
• future?: bookbags