Java 17 or 21 is already required for Portal runtime since 2024.Q2 release, but the source code was still able to be compiled on Java 8. With the 2025.Q1 release, Java 17 or 21 will also be required for compile.
Release Notes
Esta sección contiene información sobre cambios rupturistas (breaking changes) en funcionalidades y capacidades de un DXP listo para usar. Para cambios rupturistas o código interno, verifica este enlace.
When performing a GET on text fields using the headless API and results in empty contents, the output returns ”” instead of being skipped. This change gives more flexibility to the users to decide what each user will do with the information.
Users should review all GET requests on text fields to adapt to this change.
Currently, when a user make a call to Batch in order to import any entity, the error returned has a different structure than a regular call to the Rest API. Specifically, the structure that is different is the one related to "failedItems" information.
With this change, users will have the same structured information no matter the endpoint they are using so matching errors and show it in the UI will be more simple.
The main change is:
Current structure:
"failedItems": [
{ "item": "{\"properties\": {\"field1\": 4, \"field2\": 5}}",
"itemIndex": 1,
"message": "com.liferay.portal.kernel.exception.ModelListenerException: com.liferay.object.exception.ObjectValidationRuleEngineException: Field 1 must be greater than,Field 2 must be greater than 5" }
]
New structure:
"failedItems" : [ {
"item" : "{\"properties\": {\"field1\": 4, \"field2\": 5}}",
"itemIndex" : 1,
"message" : "[{\"objectFieldName\":\"field1\",\"errorMessage\":\"Field 1 must be greater than\"},{\"objectFieldName\":\"field2\",\"errorMessage\":\"Field 2 must be greater than 5\"}]"
}
]
The |
The "Warehouse" field has been removed from the Shipping Option's details panel.
This field was previously available as a selection field within the shipping option configuration, but it is crucial to understand that it was purely informational and did not enforce any actual warehouse restrictions or logistics.
The "Warehouse" field was identified as a source of potential confusion for administrators. Its presence, despite being purely descriptive, could lead to the incorrect assumption that it played a role in applying warehouse restrictions to a shipping option. To ensure clarity and prevent any misleading interpretations, we have decided to remove this field entirely.
Important Note for Administrators: If you used this field for metadata, this information will no longer be visible. We strongly recommend transferring any critical metadata to an alternative location before upgrading to avoid loss. This change does not impact actual warehouse configurations or shipping logic.
This portal-ext property was to Instance/System settings so that the property could be controlled during runtime. Users will need to reconfigure portal if they are currently using this property.
See https://github.com/liferay/liferay-portal/commit/0b2ee06d7ee20972bc8ebd84e2c1c10fb9a41763
What changed?
With the introduction of customizable publication-level permissions, all permissions, including publishing to production, can be changed by an admin or a user with the appropriate "Manage Permissions" capability.
Why was this change made?
Previously, Owners were automatically given the ability to publish content to production, which led to unintentional production changes, especially in environments using Sandbox mode or implementing stricter governance policies. This behavior was inconsistent with customer expectations and Liferay’s broader permission model.
Who is affected?
How should I update my features or implementation?
No need for Updates. You may want to use the new "Permissions" on Publication Settings section to "Edit Permissions" if needed.
What changed?
A new warning message now appears when "Sandbox Only" mode is enabled but publication Owners retain permission to publish. This does not change the behavior of Sandbox mode but introduces a new UI-level validation to prevent unwanted changes.
Why was this change made?
This message prompts admins to review permission settings and avoid potential production changes made in error. The goal is to support secure sandbox and prevent publishing mistakes by making permissions more transparent.
Who is affected?
Publication users with enough access to configure Publications and enable Sandbox mode.
How should I update my features or implementation?
No need for Updates. When enabling Sandbox Only mode, look for the new warning message and use the "Edit Permissions" option to review Owner permissions.