Users can now create, update, delete, and retrieve information about document shortcuts in a programmatic way using headless API’s. |
Release Notes
Users can now create, update, delete, and retrieve information about document shortcuts in a programmatic way using headless API’s. |
There is an unacceptable decrease in performance observed within large Publications. With publications housing a large number of individual changes, the current system struggles to maintain acceptable performance levels, especially during conflict checking and publishing publications. These two phases leverage handwritten SQL queries to perform those tasks that allow Publications a shortcut through our persistence layer to maximize performance in small publications. In large publications though, further considerations must be taken to ensure consistent performance.
Some upgrade processes may not consider the ctColectionId
column which may generate inconsistencies for customers using Publications, especially for older versions.
Add changeTrackingEnabled to the standard rest-config.yaml
so that services must specify Publications support. This will simplify the process of enabling change tracking for future Headless APIs.
We introduced a new feature to streamline workflows with 1:1 relationships between objects! Now, users can create and update nested objects directly from the primary object's CRUD views, and enjoy seamless delete and view operations translated from the Data Set Manager (DSM). This update makes managing data smoother and more efficient.
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.