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.

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\"}]"
  } 
  ]

• Granting “Update” Permissions: Granting “Update” permissions to a role enables the user to edit a folder's properties, like its name and description.

• Granting “Advance Update” Permissions: Granting “Advance Update” permissions to a role enables the user to update the workflow associated with a folder. The folder's properties, such as name and description fields, remain disabled and cannot be edited.

• Users subscribed to a web content or a folder will not receive notifications for assets in the pending state unless they are directly involved in the workflow review process

• This change is meant to match the current behavior of Documents & Media

When a user is deleted in Analytics Cloud, they will first be suppressed before being permanently deleted. As a result, you will see two requests per user—one for suppression and another for deletion.

Previously, each user deletion generated two separate requests. Now, all users are grouped into a single suppression and deletion request, reducing the number of requests. For example, each request will now contain a list of all affected email addresses instead of generating individual requests per user.

Users can verify deletion logs in:
Analytics Cloud > Settings > Data Control & Privacy > Request Log.

What changed?
A new bulk operation feature allows users to select and manage multiple changes within a publication. Users can now move or discard changes in bulk via a management bar. This simplifies managing large publications.

Why was this change made?
Previously, users had to manage each change individually, which was time-consuming. This change enhances user efficiency and reduces the administrative burden, making the platform more scalable for large publications.

Is the new behavior better for users?
It significantly saves time and effort, making it easier to manage multiple changes quickly. This results in a smoother, faster user experience when handling large volumes of changes.

Who is affected?
Users who manage large publications or need to handle multiple changes will benefit from this update. It streamlines the process for users who frequently move or discard changes.

How should I update my features or implementation to better adopt the breaking change?
If needed, this feature can be enabled/disabled through the Feature Flag on Instance Settings > Feature Flag > feature.flag.LPS-171364=true or Bulk Actions for Publications (LPD-20183)