Allow users to map Repeatable fields of a Web Content Structure already defined in Fragments and Collection Displays.
Release Notes
The /search
and /suggestions
APIs comes with the following enhancements:
New, optional
scope
parameter supporting Site (Group) IDs and External Reference Codes (ERCs) in /search. The scope parameter of /suggestions has also been updated to have the same semantics./search
now is in RELEASE status.The APIs now are available under the
/o/search/v1.0/
endpoint with backward compatibility for current/o/portal-search-rest/v1.0
calls through server-side forward.
Refer to the documentation for more details.
Elasticsearch 8.15.x has been tested and added to the compatibility matrix to the corresponding Liferay versions.
Note: Compatibility with newer Elasticsearch minor versions is tested in two ways:
Latest-Latest: Testing the latest Liferay version with the latest available minor version of Elasticsearch → e.g.
Master/2024.Q3 + Elasticsearch 8.15
Minimum-Latest: Testing the minimum Liferay version where Elasticsearch 8 compatibility was first made available with the latest minor version of Elasticsearch →
DXP 7.4 U81/DXP 7.3 U31 + Elasticsearch 8.15
This way Liferay can allow a broader deployment base to operate their stack with an up-to-date search engine version.
As Elasticsearch is usually releases a new Minor version roughly every two months, this is a recurring process and a planed activity in each quarter.
Per Elastic’s product lifecycle, Elasticsearch 7.17.x versions are supported and maintained until Elasticsearch version 9 is released. While Elastic does not provide specific release dates for future releases, for Elasticsearch 9.0.0, the new release is anticipated in early calendar year 2025.
Therefore, Liferay strongly recommends all customers with 7.17.x deployments to begin the planning phase for an upgrade project to the latest compatible Elasticsearch 8.x version.
Compatibility with Elasticsearch 8 is available on 7.4 U81+. → Operating Liferay 7.4 GA/Update 81+ with Elasticsearch 8 - Liferay
Note: The Elasticsearch 8.x compatibility is provided through the bundled Elasticsearch 7 connector and the REST API Compatibility of Elasticsearch 8.
Liferay ships with an updated Elasticsearch connector using 7.17.21 as the client version and also as version of Sidecar Elasticsearch server for development and testing purposes.
Clause Contributors configuration is now stored within the blueprint’s JSON with a smaller footprint, reducing the size of a blueprint by more than 90% when using the default setting (all contributors enabled → Enable All) or the new Disable All option.
The behavior of the different options is as follows:
with Enable All, all current and future query clause contributors introduced to the platform will be enabled automatically. Disable All behaves the opposite way,
with Customize, the configuration is locked to the specified contributor list.
The selection filters of the Data Set Manager has been revamped to allow chosing different type of sources. On top of the picklist, now the admin user may select an API Headless as filter values source, so the filter values might be populated with the values coming from the API response. This allow users to have a more automated process on the filter creation.
Data Set Manager lets from now to map Array structures, so a given cell of a Data Set can show list of values, for example to list the roles of a user or the tags of a product.
When the users are facing a Frontend Data Set the items can show actions to interact with them that are set in the Data Set Manager. From now own, when the user navigates to a destination URL through an item or creation action, the current URL is added to the destination page, so the user can return to the Data Set after performing the action seamlessly.
The CX Filter allows developers to build their own filters, with on demand bussiness logic and UI, to be added to a Data Set in the Data Set Manager and then be used for end-users in the Data Set. With this new value, the Client Extension can be generic, and the same Client Extension can be used to build filters that filter by different fields.
User session replication has been optimized for the Tomcat application server.
Users can configure a reset for the number of guest submissions allowed in a given timeframe.
Users can add the necessary security layer to avoid misuse of scripting in Objects and Workflow Actions.
In Notification Templates, users will now be able to send emails based on Account, Organization and Regular Roles.
Notification recipients will follow the permission framework that is already in place.
|
Users can now create picklists beginning with capital letters. One key feature is that now users will be able to filter by Active and Inactive values.
This will be a new configuration under System Settings and when enabled, will allow notifications from the workflow to respect the scope of the site. |
Objects is used for a wide range of use cases, some of them more technical than others. This feature will allow users to configure where they want their objects to be listed. Thus, creating unnecessary complexity and reducing cognitive load on other users.
Users can now configure their objects to observe the guest user’s locale and send email notifications based on the guest user’s language preference.
The guest user’s language preference is determined by the language the guest user used when submitting the form. If a locale cannot be determined or a notification template does not exist, then the notification will be sent in the instance’s default language.
For those Objects that have the translation active, users can not get this entry information using GraphQL. In order to improve GraphQL capabilities, we have exposed the _i18n properties, so any user can retrieve it.
Liferay has expanded GraphQL capabilities to match the functionality of REST APIs for managing object entries. Users can now transition object entries from Draft to Approved status using GraphQL, providing more flexibility and control within the development process. |
For making the Sign In portlet related functions easily customizable for the end users we want to simplify the portlet as much as we can. We need to remove all it’s configuration or functionality that can be handled in higher level.