Release Notes
Now it is possible to manage and check the permissions of the object entries directly from the headless APIs.
For each object definition, two new endpoints are available. One to retrieve the permissions that apply to that individual Object entry and another one that allows users to set/update the permissions that apply to that entry.
Now it is possible to use all query parameters available from the API explorer. Parameters such as fields, nestedFields or flatten are accessible and ready to use in your test queries.
With this feature it is possible to differentiate the login failures in the audit messages, which one is caused by incorrect password and which one is caused by incorrect login.
Before this change, audit messages were only returned for cases when the authentication failed with FAILURE status, which happens when the user provides an incorrect password. The event type is LOGIN_FAILURE in this case.
With the new changes, it is provided audit information for cases when the authentication fails with DNE status by adding a LOGIN_DNE event type. DNE stands for user "does not exist", it always means that the login (email / screenName / userID) is incorrect.
So with the newly added LOGIN_DNE event type we cover authentication DNE scenarios when the login fails due to incorrect login (email / screenName / userID) .
When the users are authenticated through SSO and IdP, it is possible to remove the ability of the end users to add or edit their passwords.
As an Instance Administrator, you are able to configure if the users have the option to give their password at registration and you can remove the whole password block from editing user data, if the password is not changeable by the password policy of the user.
The instance administrator can create email templates including the first name.
With this new feature, Instance Administrator can export audit data filtered by user as well as filtered by site. They can also store site data for audit events.
We display some additional messages to Site and Site template Administrators when there is a Friendly URL collision between Site page and Site template page.
From now on, users can view the summary of failed staging processes, which can help them to solve the issue(s) which caused the staging process to fail.
Using LAR files for export/import in the portal are stored in DM. These LAR files can increase the size of the DM significantly. We have changed this, so the LARs are not kept in the DM after the export/import process.
On LPS-136108: URLs using a virtual host are always reformatted on export and import, even in cases where they don't need to be the validation of the Web Content was added for Liferay layout URLs. Before this, there was no validation, so users could create their customizations where they could add different URLs to the Web Content's content. After the validation was added, some custom URLs became unable to be added to the Web Content. From user perspective this was a feature loss, so we decided to deliver a feature to make customers able to add their custom URLs to Web Content's content field. This feature is about adding a configuration for storing the user’s relative URL patterns. So custom URLs containing this pattern would bypass validation.
Before the Import process starts, users are now asked via a confirmation dialog if the user is sure about deleting application data . Also, we have improved the error message for Staging related references.
As a Site Template Administrator: template propagations are run completely in the background and background tasks are executed in a sequence. The LAR from the Site Template export is cached, so different Sites can reuse it.
LayoutSetPrototypeMergeBackgroundTaskExecutor always uses the latest Template version for the propagation.Two new configuration options were added:
This is the Staging related implementation of a bigger change. On the Staging side, the LXC Client extensions (Remote apps) could be handled. To make this feature completely working, LPS-182183: Export/Import of FrontEnd Client Extensions is also needed.
upgrade.log.context.name. Now all upgrade related log lines are automatically tagged with the key upgrade.component, which provides more meaningful information.Creation of a new property called upgrade.report.dl.storage.size.timeout that specifies the number of seconds that the upgrade report generation will wait for calculating the DL size before timing out. This property is set to 10 by default but it can be modified in the portal-ext.properties file.
Adds support for creating custom client extension development profiles in the same project.
For example, when the user creates a file called client-extension.dev.yaml , a new task will be available to the user called deployDev.
In order to allow developers to exclude directories from the build, a new property has been added: liferay.workspace.dir.excludes.globs=
Kaleo Forms was already in maintenance mode. It is now being moved to deprecated, so it can be removed at the same time as DDL in about a year. This solution is being replaced by Objects, Workflow, and Form Container Fragments.
The portlets that are in the Contacts module will be deprecated.
These are:
In the first step, the modules were pushed to the maintenance mode.