Aeon 3.9 Web Page Changes

Follow

Below are all changes that were made to the Aeon web pages for version 3.9. Some items include code samples to edit your web pages if you have existing customizations. You can also download the Aeon 3.9 default web pages and files on your server under C:\Program Files\Aeon\Update\Web (default location) or you can download them from the Aeon Downloads page.

These changes apply to sites updating their web pages from Aeon 3.8 to 3.9. See Aeon 3.8 Web Page Changes for previous changes.

Enhanced the Keep in Review Feature

Overview

We've made some enhancements to the existing Keep in Review feature which will improve support for request submissions from external systems. These changes will require some files in the web directory to be added or modified for existing sites to benefit from all the new functionality, but their existing web pages will continue to work. The significant change to existing behavior is that requests submitted with the "Keep for My Review" option selected are no longer validated with the web validation rules. Instead, all requests are validated at the point they are submitted for processing. This will allow the Awaiting User Review queue to act as a holding queue for any requests that may not be complete. In particular, any requests submitted from an external system that may lack certain details that would prevent them from passing web validation can now be stored in Awaiting User Review and viewed, edited to include any required details, and submitted at a later time. 

The ViewUserReviewRequests page will now show requests in review using as separate elements rather than just rows in a table. This will allow a lot more control over how each of those requests are displayed to the user. A new piece of metadata available on each request in review is whether or not it will pass web validation. If not, a message indicating that the request is missing required information will be displayed. Furthermore, when the value of the scheduled date field is changed (or any other additional field included on the ViewUserReviewRequests page, although ScheduledDate is the only one present on the default pages), the form will revalidate each request in review with this new field value and update any messages. For example, if scheduled date is a required field, requests in review will typically not have a scheduled date specified and will indicate that they are missing required information. Once you select a scheduled date on the ViewUserReviewRequests page, it will revalidate each request in review as though it had that scheduled date and update any validation messages as appropriate.

When Aeon validates requests in review, it will do so based on the the form name in their WebRequestForm field. This allows us to validate a request without having to tie to it the form it's being submitted from (previously, the validation procedure would only look for form name in the AeonForm parameter submitted from the web page).

New Features

Data Repeater Tag

The #DATAREPEATER tag allows you to define an HTML template that will be applied to each request that fits a named dataset. Currently, the only supported dataset name is "RequestsInReview". This works similarly to the fields available in the #TABLE query. The #DATAREPEATER tag has the following parameters:

  • Name: The name of the dataset to load into the repeater. Currently, the only supported option is "RequestsInReview", which loads the same dataset as the #TABLE tag loads for ViewUserREviewRequests.
  • TemplateFile: The name of the HTML template to use when displaying each request. The default web pages contain the RequestsInReviewDataRow.html file in the templates folder under the web folder.
  • NoDataAction: The message to show when the dataset does not contain any requests.

An example of how this tag is used is shown in the new default ViewUserReviewRequests.html web page:

 <#DATAREPEATER Name="RequestsInReview" TemplateFile="Templates\RequestsInReviewDataRow.html" NoDataAction="<div class='no-data-message'>You do not currently have any requests in review.</div>"> 

Data Row Tag

The #DATAROW tag is used in HTML templates referenced in the #DATAREPEATER tag to display fields from the currently loaded data row. Typically, only the follow parameter is used:
Field: The name of the field to display from the currently loaded data row. These field names will match those used with the #TABLE tag.

One special case is when you specify a field of "ValidationResult". In this case, there are two additional parameters that are supported ValidRequestMessage and InvalidRequestMessage. When the ValidationResult field is processed, the Aeon web DLL will apply web validation to the current request, and if it passes the tag will be replaced by the text defined in the ValidRequestMessage parameter; otherwise the InvalidRequestMessage parameter will be used. This provides a way to quickly show the user whether a given request has all its required information to be submitted.

Examples of the tag's usage can be found in the RequestsInReviewDataRow.html default web page, such as:

 <#DATAROW field="TransactionNumber">

and 

 <#DATAROW field="ValidationResult" ValidRequestMessage="" InvalidRequestMessage="This request is missing required information.">

 

WebValidation Changes

ScheduledDate would previously be populated with today's date if it was not provided by the user when submitting a request from review. The Aeon web DLL no longer does this and instead uses a web validation rule to require the field. Existing sites should add ScheduledDate as a required field in their web validation table if it does not already exist. The easiest way to do this is to add it to the AllRequests rule set and to ensure that every request form they support includes the AllRequests rule set in the WebFormValidationLinks table.  

Web Directory Changes

The following files have been updated as part of this feature. All of these pages should be updated or modified as described below to get the most out of the Keep in Review changes.

  • include_header.html
  • ViewUserReviewRequests.html
  • css\main.css
  • js\KeepInReview.js
  • templates\RequestInReviewDataRow.html (new file)

The changes to each of these pages are detailed below.

include_header.html

The following attributes were added to the #status div (i.e. <div id="status">)
aria-live="polite" aria-label="Status message region"

ViewUserReviewRequests

There were many small changes made to the page to clean up the organization and presentation, but the most important ones are:

The ViewUserReviewRequests table is replaced with the new data repeater feature. i.e. the section

 <div class="default-table">     <#TABLE name="ViewUserReviewRequests" headerText="Requests In Review" noDataAction="ShowMessageRow" noDataMessage="No Requests" sortable="true"    column="TransactionNumber:TN" column="Title" column="ItemAuthor:Author/Creator" column="CallNumber:Call&nbsp;Number" column="ItemVolume:Volume/Box" column="TransactionStatus:Status" orderby="TransactionNumber DESC"> </div>

is replaced with: 

 <#DATAREPEATER Name="RequestsInReview" TemplateFile="Templates\RequestsInReviewDataRow.html" NoDataAction="<div class='no-data-message'>You do not currently have any requests in review.</div>">

and the #ScheduledDate input adds the following attribute:
onchange="aeonKeepInReviewModule.revalidateRequests()"

main.css

The following section should be added to the main.css file.

/* Keep In Review */
#ViewUserReviewRequests label .field {width: 58%}
/* Data table rows */
.no-data-message
{
 margin: 1.2em 0;
 font-size: 120%;
 color: 0;
}
.table-data-row
{
 margin: 0.2em 0 1em;
 overflow: hidden;
 background-color: #EFEFEF;
 border-style: solid;
 border-color: #888;
 border-width: 0.1em;
}
.table-data-row-details
{
 float: right;
 min-height: 1em;
 width: 82%;
 padding: 0.5em 1%;
 margin: 0;
}
.table-data-row-details .item-title
{
 font-weight: bold;
 color: black;
}
.table-data-row-details .item-author
{
 color: #666;
}
.table-data-row-actions
{
 float: left;
 min-height: 1em;
 width: 14%;
 padding: 0.5em 1%;
 margin: 0;
}
.table-data-row-actions input
{
 padding-top: 5px;
}
.table-data-row-actions a
{
 color: #333;
}
.table-data-row-actions a:hover
{
 /*text-decoration: underline;*/
 color: #666666; 
}
.table-data-row-metadata
{
 clear: both;
 min-height: 1em;
 overflow: hidden;
 border-top-width: 0.1em; 
 border-top-color: #888;
 border-top-style: solid;
 background-color: white;
}
.table-data-row-metadata .validation-message
{
 float: left;
 width: 68%;
 padding: 0.5em 1%;
 margin: 0;
 color: #CC0000;
 font-weight: bold;
}
.table-data-row-metadata .creation-date
{
 float: right;
 width: 28%;
 padding: 0.5em 1%;
 margin: 0;
 color: #666;
 text-align: right;
}

KeepInReview.js

The KeepInReview.js file has been significantly changed and should be overwritten with the latest version. If any customizations have been made to this file that differ from the default version, those changes will have to be reevaluated on a case-by-case basis. 

The one exposed method from this file that one should be aware of when editing the ViewUserReviewRequests page is the aeonKeepInReviewModule.revalidateRequests() method. This is used on the default page on the ScheduledDate field, and when called as part of the onchange attribute will cause Aeon to revalidate all of the requests in review and update any messages regarding their validation status.

Note that this file will have to be modified if a site wants to customize the validation messages that are shown on the ViewUserReviewRequests page. Those messages are defined both in the ValidRequestMessage and InvalidRequestMessage parameters of the #DATAROW tag in templates\RequestsInReviewDataRow.html and in the string variables defined near the beginning of the KeepInReview.js file named validRequestMessage and invalidRequestMessage.

RequestInReviewDataRow.html

This is a new file referenced from the ViewUserReviewRequests page. It is contained in the new 'templates' directory under the web directory and is intended to store page templates that are used by the new data repeater feature.

Keep in Review - EAD requests that fail validation will now still be submitted but kept in user review

This behavior will be the standard for new installations. If an existing Aeon site wants this feature where EAD requests do not require web validation to be submitted some web changes will be required. The existing sites will need to replace their EADRequest.js file with the new version. The new version of the EADRequest.js removes all web validation that was being handled before the request was being submitted. Please see the Aeon Downloads page to download the 3.9 web pages to get the revised EADRequest.js file.

User Request Limit

The user request limit will continue to act as it had before. Aeon will be optimistic that all of the requests that are being submitted from the EAD request form will pass validation. If the total number of requests being submitted exceeds the user request limit, all requests will instead be kept in review. 

Validation

The web validation will now be handled by the server when the requests are submitted. It is possible that some requests will be ok while others will fail validation. Requests that have no validation issues will be routed to the appropriate status. Requests that fail web validation will be kept in review.

Updating existing sites

If an existing Aeon site wants this feature where EAD requests do not require web validation to be submitted some web changes will be required. The existing sites will need to replace their EADRequest.js file with the new version. The new version of the EADRequest.js removes all web validation that was being handled before the request was being submitted. 

New Tags for SLEADRequestsReceived

  • <#SubmittedTransactionCount> - Indicates the number of requests that were submitted that were not kept in user review
  • <#ReviewTransactionCount> - Indicates the number of requests that were kept in user review
  • <#SubmittedTransactionList> - Comma-separated list of requests that were submitted that were not kept in user review
  • <#ReviewTransactionList> - Comma-separated list of requests that were kept in user review
  • The <#TransactionList> will continue to function and shows all requests that were received (acts as a combination of SubmittedTransactionList and ReviewTransactionList)

As an example, the SLEADRequestsReceived key is set to: 

  • <#SubmittedTransactionCount> submitted (<#SubmittedTransactionList>). <#ReviewTransactionCount> requests added to review (<#ReviewTransactionList>). Transaction(s) <#TransactionList> received.

ScreenCapEADRequestsSubmittedwithreview.png

Request submissions do not preserve data if the user is expired and has to first update their information.

The DLL will now preserve data if a user is expired and has to first update their information.Sites who want this functionality will need to update their ChangeUserInformation.html page (or their ExpiredUsers.html page if they use that) to add a FormState tag.

<div id="content" role="heading" aria-label="Content"> 
 <form action="aeon.dll" method="post" 
name="ChangeUserInformation" class="f-wrap-request"> 
<input type="hidden" name="AeonForm" value="ChangeUserInformation"> 
 <input type="hidden" name="NotificationMethod" value="Email">                     
 <#FORMSTATE> 
 <fieldset> 
 <legend>Change Personal Information>/legend>

Logout.html file missing closing <div> tag

Added closing <div> tag at line 24 in the Logout.html file. 

 <p>If you are not redirected within five seconds, <a href="<#PARAM name='LogoutUrl'>">click here.</a></p>

  <#INCLUDE filename="include_footer.html">
  </div></div></div></body>

All CreditCardPayment.html pages

We removed the leading slash from "/aeon.dll" in the tags where it is combined with the WebURL to prevent double slashes when WebURL ends with a trailing slash (which it should). These changes were made to all three feature-specific CreditCardPayment.html pages.

<#CUSTOMIZATION name="WebURL">/aeon.dll?action...

 becomes: 

 <#CUSTOMIZATION name="WebURL">aeon.dll?action...

 Existing sites do not need to update their pages if their credit card processing is working as is.

PayPal and Authorize.net CreditCardPayment.html pages

The javscript on the CreditCardPayment.html pages for PayPal and Authorize.net have been updated to prevent issues caused by caching that Internet Explorer does. The feature-specific pages are available on the Aeon Downloads page. In the Authorize.net version, we added a "cache: false" setting to the $.ajax() call located in the $(document).ready() function. In the PayPal version, previously we were using the $.get() function which doesn't allow us to disable caching. In this case, we replaced it with a $.ajax() call which necessitated some changes to the parameters we were passing in. When updating existing sites that use PayPal, it will probably be easiest to just replace the entire body of the $(document).ready() function.

ActivityInformation.html table Accessibility

Updated the tables on the ActivityInformation.html page to the new table header convention for accessibility purposes. 

 Before:

 After:

<div class="default-table simple-table">
 <table class="default-table">
 <thead>
 <caption>Activity Information</caption>
 </thead>
 <tbody>
 <tr class="row-even">
 <td>
Name
 </td>
 <td>
 <#ACTIVITY field="Name">
 </td>
 </tr>
 <tr class="row-odd">
 <td>
Description
</td>
 <td>
 <#ACTIVITY field="Description">
 </td>
 </tr>
 <tr class="row-even">
 <td>
Type
 </td>
 <td>
 <#ACTIVITY field="ActivityType">
 </td>
 </tr>
 <tr class="row-odd">
 <td>
Status
 </td>
 <td>
 <#ACTIVITY field="ActivityStatus">
 </td>
 </tr>
 <tr class="row-even">
 <td>
Status Date
 </td>
 <td>
 <#ACTIVITY field="ActivityStatusDate">
 </td>
 </tr>
 <tr class="row-odd">
 <td>
Location
 </td>
 <td>
 <#ACTIVITY field="Location">
 </td>
 </tr>
 <tr class="row-even">
 <td>
Begin Date
 </td>
 <td>
 <#ACTIVITY field="BeginDate">
 </td>
 </tr>
 <tr class="row-odd">
 <td>
End Date
 </td>
 <td>
 <#ACTIVITY field="EndDate">
 </td>
 </tr>
 </tbody>
 </table>
 <br/>
 </div>
<div class="default-table simple-table">
 <table class="default-table">
 <thead>
 <caption>Activity Information</caption>
 </thead>
 <tbody>
 <tr class="row-even">
 <th scope="row">
Name
 </th>
 <td>
 <#ACTIVITY field="Name">
 </td>
 </tr>
 <tr class="row-odd">
 <th scope="row">
Description
 </th>
 <td>
 <#ACTIVITY field="Description">
 </td>
 </tr>
 <tr class="row-even">
 <th scope="row">
Type
 </th>
 <td>
 <#ACTIVITY field="ActivityType">
 </td>
 </tr>
 <tr class="row-odd">
 <th scope="row">
Status
 </th>
 <td>
 <#ACTIVITY field="ActivityStatus">
 </td>
 </tr>
 <tr class="row-even">
 <th scope="row">
Status Date
 </th>
 <td>
 <#ACTIVITY field="ActivityStatusDate">
 </td>
 </tr>
 <tr class="row-odd">
 <th scope="row">
Location
 </th>
 <td>
 <#ACTIVITY field="Location">
 </td>
 </tr>
 <tr class="row-even">
 <th scope="row">
Begin Date
 </th>
 <td>
 <#ACTIVITY field="BeginDate">
 </td>
 </tr>
 <tr class="row-odd">
 <th scope="row">
End Date
 </th>
 <td>
 <#ACTIVITY field="EndDate">
 </td>
 </tr>
 </tbody>
 </table>
 <br/>
 </div>

 

 

Questions?

If this article didn’t resolve your issue, please take a moment and answer a few questions to help improve our documentation:

Feedback