The password reset email template should be hidden in client email template options.

The activity grid in Aeon 5.0 doesn't save any changes made to the layout after the client has been restarted.

v5.0
Bug# 4449

In Aeon 3.9 the date values would be exported as a date value which you could then sort chronologically. In Aeon 4.0, the new values only allow you to sort them alphabetically unless you manually remove the AM/PM text from all the cells and change the format of the cells to a date format.

v4.0 & 4.1 & 5.0
Bug# 4432

When you set the StaffPreviousPassword to 0, Aeon should default to checking a minimum of 4 unique passwords before an old password can be reused. Instead, a bug is causing the system to read the 0 as a null value, which in turn made it to unable to recognize any passwords. Until the bug is fixed, do not set the default value to 0.

v4.1
Bug#4238

Field customizations made for staff templates were no longer displaying in the client

v4.1
Bug#4217

Bug#3910

Blocked users are able to resubmit requests when changing the schedule retrieval date on Cancelled and Awaiting User Review requests.

Bug#3845

When creating Aeon's BillingDefaults table and you enter a row into the table that maxes out the MSSQL fields, you will receive the following error:

Warning! The maximum key length for a clustered index is 900 bytes. The index 'PK_BillingDefaults' has a maximum length of 1120 bytes. For some combination of large values, the insert/update operation will fail.

Some web users have been able to re-submit requests after they are placed in statuses that should not allow re-submission.

Invalid data row displays when "Show Auto Filter Row" option is turned on

A default database user and password are hard-coded into the installer defaults. When the DB update scripts try to grant permissions on new or updates tables, it will always try to grant them to 'aeon'. Need a way to configure the database user/password on install if different from hard-coded 'aeon'.

When an individual user has a request limit of “0” set in the client (so that the user can have unlimited requests), that “0” then shows up in web status lines as the user’s request limit if the <#requestlimit> tag is used in any status lines."

Status line message: "Thank you for your request(s). If you have more than 0 active requests, your requests will be placed in review and you will need to submit individual requests from the Saved Requests page."

Should clarify message if request limits are used overall, but individual user has unlimited limit.

Using the web request form, users can enter a new/blank line(s) before the item's title. That character is saved in the database causing the ItemTitle Field to appear blank in the client's grid view, and missing in the email templates when the ItemTitle tag is used.

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.