Aptify 7.5 Resolved Issues

This document contains the bug fix descriptions and support recommended improvements for Aptify 7.5 release and is divided into the following categories:

• Business Application Improvements
• Orders and Payments Improvements
• e-Business Improvements

Business Application Improvements

Order Line Attendee Names Disappear

When an order was generated for the same meeting product with four or more order lines in Aptify Web, each having a different attendee name, the order was initially created correctly. However, upon reopening the order, attendee names were missing from the second order line onward.
Now in Aptify web 7.5 the issue causing the attendee names to not display on reopening the order has been identified and resolved. All order lines retain and correctly display the associated attendee names as expected.

(Issue 8502)

Two drop-down show incorrect data in base view field

In General tab of any field in an entity’s base view, the EntityField and SQLData dropdowns displayed incorrect information. The issue was verified on stock implementation, SQLData was confirmed to be working correctly, and the problem was isolated to the EntityField dropdown. So, fixes were applied to the EntityField dropdown logic. After the update, EntityField now displays the correct information.

(Issue 9075)

Calendar View Rendering and Sub-Class Creation Behavior in Classes

Previously in Aptify, the calendar view under "Sessions > By Location" failed to respond when no sub-classes were present. This issue has been resolved, now the calendar renders correctly even in the absence of sub-classes.

Additionally, an issue with sub-class creation has been fixed where new sub-class forms opened from the calendar view did not auto-populate the parent class ID. This update ensures that new sub-class forms now retain the proper parent-child relationship, preventing incorrectly linked or unlinked records.

(Issue 8927)

Consolidated: BluePay implementation should be part of stock in 7.5

In Aptify Web, when using Hosted Payment Page (HPP) for processing payments, the Initial Payment Amount was not being updated correctly. The issue has been identified and resolved in 7.5 release; the Initial Payment Amount now updates as expected during transactions processed through HPP.

(Issue 9010)

Aptify Web: Topic Codes Do Not Save for Meetings

In Aptify Web, when users added the Topic Code tab to the Meeting entity, any topic codes entered were not being saved. This functionality was not previously supported. With the 7.5 release, users can now add and update Topic Codes for the Meeting entity successfully.
(Issue 9009 and 9056)

Orders and Payments Improvements

Additional information for CardPointe Payment

In alignment with the CardPointe Payment guidelines, the CardPointe transaction page has been updated with the following changes:

• Card Name Display (Based on OrderParty):
  The display logic for the cardholder's name now dynamically reflects the type of OrderParty:
  
  • When OrderParty = Company: Displays the Company Name (Company.Name)
  • When OrderParty = Individual: Displays the Person Name (Person.FirstName Person.LastName)
• New Custom Field – OrderParty:
  A new field named OrderParty has been introduced to ensure consistency with the updated naming conventions in the Orders entity. This field distinctly identifies the type of party (Company or Individual) associated with the order.
  Note: This is separate from the existing Order Type field and specifically reflects the selected OrderParty type. The name has been retained as "OrderParty" to maintain parity across entities.
• Renamed Custom Field – PersonID:
  The PersonID field has been updated to conditionally display data as follows:
  
  • If Person details are available: Displays the respective PersonID
  • If unavailable: Defaults to "[Not Specified]" with ID2542

These updates aim to enhance data clarity and ensure consistency across related entities in the transaction workflow.

(Issue 9066)

Prompt Views Use Cached Values

In version 7.x, prompt views failed to export the correct data to Excel when prompt parameters were changed between executions. The issue was fixed by updating the `Aptify.Framework.Views.Utility.UI.js` file. After the fix, prompt views now correctly export data to Excel based on the current prompt parameters, ensuring accurate and expected results.

(Issue 8912)

e-Business Improvements

Ebiz React - Forgot Password Emails Do Not Trigger if Web User ID is Not Email

Previously, the Forgot Password feature only worked if the USERID/USERNAME was the user's email address. If it was not, the password reset email would not be sent.

In the Aptify e-Business React 7.5 release, the Forgot Password process has been improved to support usernames that are not email addresses. Now, even if the USERID/USERNAME is not the user's email ID, the password reset email will be successfully sent to the email address specified in the Email field under the user's profile.

(Issue 9070)

e-Business Usernames / Email Do Not Accept Apostrophes

Previously, users were unable to create an account or reset their password if their username or email address contained apostrophes (e.g., o'[e-mail]). This issue has now been resolved. The e-business platform now fully supports usernames and email addresses with apostrophes for both signup and login processes.

(Issue 8866)

Required State Field for U.S. and Canada Addresses

In earlier versions of Aptify e-Business React interface, we have address component on billing-shipping page and profile page which allowed users to add new address or perform edit/update on existing address which does not have State mandatory field. 

The expected behavior is that the "State" field becomes mandatory only when "United States" or "Canada" is selected in the "Country" field and remains optional for all other countries.

Fix had been provided in this release to address this issue. Now, for the country Canada and United States the state field is mandatory. For any other country other than these two state is not mandatory field.

(Issue 2566)

SAML Integration Enhancements (Aligned with SAML 2.0 Specification)

We have made significant improvements to our SAML authentication flow to better align with the SAML 2.0 specification and enhance compatibility with third-party Service Providers. Key updates include:

 Structural Enhancements in SAML Response:

• Signature Handling Updated:
  The digital signature is now embedded inside the <saml:Assertion> element (instead of the top-level Response), as required by many SAML Service Providers
  Additionally, the signature element is now explicitly prefixed with ds: (i.e., <ds:Signature>), as expected by many SAML Service Providers and tools.

• Canonicalization and Namespace Formatting:
  Improved formatting and usage of exclusive XML canonicalization (http://www.w3.org/2001/10/xml-exc-c14n#), and standardized namespace declarations to avoid signature verification issues.

 Assertion-Specific Additions:

• Audience Restriction:
  Added <saml:AudienceRestriction> inside <saml:Conditions> to clearly define the intended audience of the assertion, reducing the risk of misuse.

• Subject Confirmation:
  Added<saml:SubjectConfirmation> with Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" and associated attributes such as Recipient, NotBefore, and NotOnOrAfter to tighten assertion usage constraints.

 Attribute & Authentication Enhancements:

• Added the AuthnStatement including AuthnContext to properly reflect urn:oasis:names:tc:SAML:2.0:ac:classes:Password to indicate password-based login context.

 Compatibility & Spec Alignment:

• All enhancements are based on the official SAML 2.0 specification, ensuring seamless integration with federated identity platforms, and improved validation across standard-compliant SAML toolkits (samltool.com, samltool.io)

• These updates also pave the way for easier adoption of other SSO and federated authentication flows in the future.