You can limit the number of active requests your users can submit at one time. Universal and status-based request limits are set in the Customization Manager and individual request limits for users are set on the user record in the Aeon Desktop Client or Aeon Web Client. If configured to display, a notice appears at the top of the user's web pages indicating the number of active requests and the number of allowed requests. When a user has reached the set limit for requests and attempts to place another request from the web, a notice appears on the request form informing the user that the request limit has been reached, and the request cannot be submitted.
Note that request limit counts are enforced by the transaction's initial queue status when the request is created and will not take into account any routing rules that may automatically move the request into a new status after it is created. A user may be able to surpass the request limit if a routing rule moves a newly created request from an initial queue that does not count toward the request limit into a queue that does count against the request limit. See the Specifying Queues Included in Request Limits section for more information on configuring which queues count against the request limit.
If a request is sent to a custom queue that is based on the state of a queue that is configured to be used in request limits, (for instance, an "Awaiting My Processing" custom queue created from "Awaiting Request Processing"), the DLL will count the request based on Awaiting Request Processing.
Upon installation of the system, Aeon can be configured with numerical limits that govern the number of active requests allowed per user at any given time. There are three types of User Request Limits referenced by the Aeon DLL. These are:
- Universal Request Limits. Set using the RequestLimit key. Default Value is 0, which is interpreted by the system as allowing unlimited requests.
- Status-Specific Request Limits. Set using custom RequestLimit keys, such as RequestLimitFaculty.
- Individual Request Limits. Set in Request Limit field on the user record in the Aeon Desktop Client or Aeon Web Client.
Request Limit Hierarchy
The UserRequestLimit customization key, when set to Yes, checks for individual and status-specific limits before the system allows default universal request limits. Aeon first looks for an individual request limit from the RequestLimit value in the Users table (this number comes from the Request Limit field of the user record in the Staff Client). If there is an entry there, that number is used. If that value is empty, the system then checks for a status-based request limit. Aeon looks for a value in the RequestLimit<Status> customization key, if the key exists. If there is a number there, that number is used. If Aeon does not find an individual or status-based request limit, it uses the default universal value of the RequestLimit customization key.
Empty values in the individual and status-specific checks indicate that a limit has not been specifically set on those levels. Also, a value of 0 indicates that request limits are turned off for a specific user, status, or overall (meaning the system allows unlimited requests). The 0 value is also the internal default in case an invalid value is entered.
Universal Request Limits (Default)
By default, all Aeon users are assigned the same numerical limit. This number is specified by the RequestLimit key. The default value for this RequestLimit key is 0. The RequestLimit key can be found in the Customization Manager under Web Interface | Limits and may be changed to better reflect your institution's requesting policies. A value of 0 will be interpreted by the system as allowing unlimited requests. Unless status-specific or individual limits are being used, every user will be limited to the number of active requests specified by the RequestLimit key. There is no value shown in the Request Limit field of the user record in the Staff Client when the RequestLimit key is being used.
Status-Specific Request Limits
To assign separate request limit values to each user status that will be used in your system. This effectively overrides the RequestLimit key (discussed above) and allows you to have one limit value for Faculty users, a different limit value for Undergraduates, and so forth.
Adding Status-Specific Request Limit Keys to the Customization Table
To implement status-specific request limits, you must first make some additions and/or modifications to the Customization table. You will need to add RequestLimit keys into the Customization table for each user status that will be used in your Aeon system. To add a status-specific request limit to the Customization table, open the Customization Manager and navigate to System | General | Customization.
This will open the Customization table for editing.
-
The status portion of the RequestLimit CustKey value (e.g., "Faculty " in RequestLimitFaculty) for each of these entries MUST be identical to the actual status assigned to the users. Spelling and case are important.
For multi-word patron statuses separated by spaces, like "Graduate Assistant," the key name should include the space, i.e. RequestLimitGraduate Assistant. - Each key can have its own numeric value for the number of active requests allowed for that status. This is stored in the Value field. A value of 0 will be interpreted by the system as allowing unlimited requests.
Once all of the needed RequestLimit entries are entered into the Customization table, set the key value for the UserRequestLimit key to Yes. This key can be found in the Customization Manager under Web Interface | Limits.
A new entry for a customer status of Faculty with a request limit of 5 active items would look something like this:
| Field Name | Value |
|---|---|
| CustKey | RequestLimitFaculty |
| Value | 5 |
| Description | Request Limit for Faculty Users |
| AdminCat | Web Interface |
| AdminKey | Limits |
| AdminType | StringValue |
Using Status-Specific Request Limits
Once this feature is enabled, users will be limited in the number of active requests allowed by the Aeon DLL based on the value set for their status. This is the value that will be looked for by the Aeon DLL each time a user attempts to submit new requests. If user records exist in the system prior to the implementation of status-specific request limits, these records will automatically adopt the status-specific limits. There is no value shown in the Request Limit field of the user record in the Staff Client when the RequestLimit key is being used.
Individual Request Limits (Exceptions to the Rule)
There may occasionally be a need to make exceptions to the assigned request limits. To do this, pull up the user record for the user needing an exception in either the Aeon Desktop Client or Aeon Web Client and change the value of the Request Limit field to the appropriate number. Be sure to save changes before exiting the form. The presence of this value on the user record will instruct the Aeon DLL to use it rather than any other specified limits. You can view this information in the Additional Information section of the user record in either the Aeon Desktop Client or Aeon Web Client.
Specifying Queues Included in Request Limits
You can choose which queues are included in request limits by checking or unchecking the box the Include In Request Limits option of the queue record in the Queues table.
There are 5 queues used to determine request limits by default. You can uncheck the Include In Request Limits option on the queue record to remove them from the request limit count. Note: Photoduplication queues are not included in the request limits by default but can be added.
- Awaiting Future Request Processing
- Awaiting Request Processing
- In Item Retrieval
- Item Checked Out
- Item on Hold
Remember that new requests will only exceed request limits if the initial status of the request at the time of its creation is included in the statuses that count toward request limits. For example, if only the In Item Retrieval queue is marked to be included in Request Limits, patrons will still be able to submit any number of requests because the preceding queues (Awaiting Request Processing, Awaiting Future Request Processing, or Awaiting Activity Processing) were not marked to be included in the request limit list. Requests created by users typically originate in one of the following queues:
- Awaiting User Review
- Awaiting Activities Processing
- Awaiting Future Request Processing
- Awaiting Request Processing
- Awaiting Order Processing
- Awaiting Order Submittal
In addition, if a user has reached the request limit and tries to resubmit a canceled request, the request will not be submitted.
Request Limit Handling for EAD Requests
As of Aeon Server v5.1.14, the SubmitEadRequestsUpToRequestLimit customization key (located in the Aeon Customization Manager under Web Interface | EAD) allows you to configure how Aeon will handle requests submitted from the EAD request form when the number of requests submitted would exceed the user's request limit:
- When the key is set to Yes:
- Aeon will submit as many requests as possible up to the request limit. These requests will be routed to the Awaiting Request Processing status for processing
- The remaining requests that would exceed the request limit will be routed to the Awaiting User Review status
-
The user will be shown the SLEADRequestsReceived status line stating the number of requests submitted for processing and the SLEADRequestsReceivedUserReview status line stating the number of requests saved for review
Note: The user will not be able to choose which requests are submitted for processing and which are kept for review.
- When the key is set to No (default):
- All requests will be routed to Awaiting User Review and the user will be shown the SLEADRequestsReceivedUserReview status line
Example Behavior
If a user's request limit is set to 5 and the user attempts to submit 6 requests from the EAD request form:
- If the SubmitEadRequestsUpToRequestLimit customization key is set to Yes, then the first 5 requests will be submitted and routed to Awaiting Request Processing. The remaining request will be saved to the Awaiting User Review status. The SLEADRequestsReceivedUserReview and SLEADRequestReceived status lines would both display indicating that 5 requests were submitted for processing and 1 request was saved for user review.
- If the SubmitEadRequestsUpToRequestLimit customization key is set to No, then all 6 requests will be saved to the Awaiting User Review status and the SLEADRequestsReceivedUserReview status line will display indicating that 6 requests were kept for review. The user can then navigate to their Saved Requests page and manually submit requests up the 5 request limit.
Status Lines Related to Request Limits
There are three status lines related to request limits that can be configured to display on the user's web pages:
- SLActiveRequest: Displays the number of active requests held by the researcher.
- SlActiveRequestWithLimits: Displays the number of active requests held by the researcher along with the request limit that has been assigned.
- SLRequestLimitMet: Displays on a request form if a user attempts to submit a request but has already reached the request limit. Only appears if RequestLimit is set to something other than 0.
These SLActiveRequest and SLActiveRequestWithLimits status lines display along with the request received status lines shown below:
- SLMainMenu: shown on MainMenu.html
- SLShowUserReview: shown on ViewUserReviewRequests.html
- SLShowRequest: shown on Default and GenericXXXX request forms
- SLRequestReceived: shown after a new loan request is submitted
- SLRequestReceivedUserReview: shown after a new loan request is submitted with the Keep in Review/Save Request for Later option selected
- SLRequestReceivedWithEstimate: shown after a new copy order is submitted for an automated estimate
- SLRequestReceivedSkipEstimate: shown after a new copy order is submitted without an automated estimate
- SLSubmitUserReview: shown when requests are submitted from the ViewUserReviewRequests.html form
If your site is not using request limits, the SLActiveRequest and SLActiveRequestWithLimits keys should be blank to ensure that the request received status line displays properly.
EAD Request Status Lines
Two additional status lines will conditionally display for requests submitted via the EAD request form based on whether the number of requests submitted would exceed the user's request limit and also based on the value in the SubmitEadRequestsUpToRequestLimit customization key:
- SLEADRequestsReceived: shown after new EAD requests are successfully submitted for processing
- SLEADRequestsReceivedUserReview: shown when submitted EAD requests are kept in user review