Tag filter widget used to sort tags in alphabetical order but it seems customers expect to see the tags with more uses first. We think this change make sense so we have modified the behavior for this widget.

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

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.

The deployFast Gradle task gave developers a way to hot deploy compiled JSPs into the Liferay bundle work folder as a way to reduce the deployment time of OSGi bundles. However, the speed improvements it gave were insignificant and it also depended on underlying system functionality that allowed overriding JSPs in the Liferay work directory, which has been removed.