This feature empowers users to create content use cases on top of objects framework, allowing admins to enable localization for objects' entries text fields.

This feature allows customers, who need more capabilities than what the out of the box Expression Builder provides, to add their custom validations in Objects framework without running their data through an external microservice.

Now, users are able to fill out object entries in parts, allowing them to save data as draft and return at their convenience to complete.

Evolving the user experience when object validations fail specifying which information field end-users need to update.

This feature allows admin users to configure whether to send one email with everyone in copy or many emails individually to each email address.

Enabling this feature will allow users to dynamically populate fields using expressions with information created from data filled and provided by other fields.

Traditionally in Liferay, it has been hard to manage features deprecation because customers kept using the old features even if we announced deprecation and eventual replacements.

Now, we are able to better manage deprecation processes with the following changes:

• Features deprecation notice is increased from 6 months to 12 months. It applies to the Intended Functionality, as described in our Support Policy.
• Now, deprecated features might be kept inside a Deprecation Feature Flag during the deprecation period. These feature flags work as follows:
  • For upgrades, Deprecation Flags are active by default, therefore customers still see the deprecated feature. No disruption is perceived.
  • For new instances created, Deprecation Flag is inactive by default, therefore, the deprecated feature is hidden and it requires activation to be used. It prevents users from unconsciously using a deprecated feature.

• Deprecated features are identified in DXP with a new deprecation badge.

When “Manage Users” permission is added to an Account Admin, the Admin can invite, assign and create Users. We separated the “Invite User” permission so it can be used without providing the other permissions to the User.

Before this feature when somebody wanted to activate/deactivate a User they needed to have “Delete” permission. We created two new permissions called “Activate” and “Deactivate”. Users with “Delete” permission still able to activate/deactivate users.

We also created two new Headless-API endpoint:

/headless-admin-user/v1.0/user-accounts/by-status/${status}

Status can be either "active" or "inactive," allowing you to fetch users by their status.

 /headless-admin-user/v1.0/user-accounts/by-email-address/${emailAddress}

This endpoint lets you retrieve a user by their email address, regardless of their current status.

This feature addresses the inconvenience of not being able to remove specific entries from user invitation forms, enhancing the user experience for admin users who create these forms. It solves the problem of inefficient form management, allowing users to remove entries without starting over.

The feature enables users to remove entries from the invitation form by clicking a designated removal button, with a confirmation modal to prevent accidental removal.

We extended the Audit Log info on IMPERSONATION actions , ASSIGN/UNASSIGN events involving the role assignment of individual users and ASSIGN/UNASSIGN Role Assignment of Organizations/User Groups/Sites.

We have expanded our Headless Admin User API to include POST, PUT, DELETE, and PATCH endpoints for managing postal addresses associated with user accounts. This development aims to provide more comprehensive functionality and greater flexibility for our users. Additionally, we've made crucial changes to the UserAccount schema and related methods to allow users to manage user status efficiently.

It is now possible to set an expiration on the “set new password” link.

Now users can export the Frontend Client Extensions that have been registered through the UI and import them in other instances. The system will generate a JSON file with all the information needed.

In order to use supported JDK versions, we are upgrading to Gradle 7 to use newer JDK.

The integration of ChatGPT with our Web Content editor is now available OOTB.

Now the “Theme SVG Spritemap” frontend client extensions is enabled by default.

Now the “JS Import Maps Entry” frontend client extensions is enabled by default.

Dynamic Data Lists is deprecated and replaced by Objects. DDL has been deprecated as of 7.3, and the Deprecation flag was added to prevent new integrations using DDL (customers that upgrade will still see it).

DDL is planned to be removed in 2024, please migrate your data to Objects before then.

Compatibility with IBM WebSphere application server has been deprecated as of Q4.2023. Please migrate to another application server on the Compatibility Matrix. WebSphere compatibility is expected to be removed at the end of 2024.

Compatibility with Java JDK 8 runtime has been deprecated as of Q4.2023. Java JDK 11 is now the recommended runtime environment. All Java Technical Compatibility Kit (TCK) compliant builds of Java 11 are certified. DXP source compile and runtime compatibility for a higher Java JDK is expected in 2024.