When routing a request to another site (that is still visible by the existing view), the request will remain open.

The code for barSubItemRouteToSite_ItemClicked is routing to RequestInProcessing regardless of it the originalStatusRequestProcessing variable is -1 or something else. The route to RequestInProcessing in the else (i.e. when the request is still visible) should only happen if the originalStatusRequestProcessing is not equal to -1.

This was discovered in a very particular situation but is still good to account for.

Go to Aeon Customization Manager.
Edit the SLMainMenu customization key.
Change the value to <#STATUS>.
Log on to Aeon Web.

In the Aeon Client, open a request and modify a text field so that it is highlighted yellow to indicate pending changes.
Routing the request (both request status routing and photodup routing) or selecting a next step (other than Cancel) will immediately perform that action without prompting to save changes. The route options may prompt you to confirm that you want to route if you haven't checked the "Don't show this again" checkbox, but you won't be prompted to save pending changes.

n InitializePostData, the DLL loops through the name/value pairs from the request content and decodes their values. However, it does not decode the field names. This isn't often a problem, but the Georgia Tech XSLT submits field names with a + character, which are getting encoded. When the EAD Request function tries to find field names using the identifier, they don't match because the + is still encoded in the field name. (We've since updated GT's XSLT to work around this).

The mail merge data files need to be XLSX in order to overcome data length limitations in the XLS format.

Add a web validation rule for the "RequestLink" field with a validation rule of ".+" that will be applied to submitted EADRequests.
Submit an EAD request.
The new request will fail web validation and be left in Awaiting User Review.

Transaction numbers do not get to Touchnet due to an issue with ancillaryData handling.

Bug# 10472

The "Unable to process payment at this time. Please contact library staff if this problem persists. Response signature provided from CyberSource payment provider could not be confirmed." error occurs when a user makes a payment in CyberSource but closes out before successfully navigating back to Aeon.

Bug# 9361

When scaling an item record's window down, the notes field becomes inaccessible, even when a note is present.

Bug# 10317

The ApiKeyAuthenticationMiddleware layer is invoked unnecessarily for non-secure endpoints, resulting in invalid X-AEON-API-KEY header log statements.

Bug# 10273

Once the h5 header is updated to h4, there is an empty header that breaks accessibility.

Bug# 10178

Bug# 9085

Users can submit duplicate requests through external requesting by rapidly clicking the submit button.

Bug# 4702

When adding a transaction to a bundle, Aeon is creating an entry in the History table. The Entry column is limited to 255 characters, which throws an error if the bundle has a name that exceeds the limit.

Bug# 8806

When a user submits a request, the request is created as expected after logging in. Then, if the user clicks the refresh button in their browser, a duplicate request is submitted.

If the user is already logged in and attempts to refresh after submitting the request, I get the: "This form has already been submitted. Duplicate request not created." error as expected.

Bug# 8826

For example, validating a transaction without username results in the following:
2x "username can't be empty"
1x " is not a valid username"
1x "user cannot be anonymous"

Bug# 8889

Bug# 9003