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.

• Solution introduces 2 breaking changes in the data model, because of a “limitation” in the root model assumptions

  • There were 2 relationships connecting Data Set and Data Set Action depending on the type of action. Now there is only one

  • type field in Data Set Action object definition has changed. Now it stores the type of action (item, creation, bulk). The old type now goes to target field

• As a result, previously saved data set actions will not be manageable by DSM, neither fragment will find them.

According to the deprecation feature flag pattern definition, the feature flag has been moved under Instance Setting.

The Collection Page has been removed from the page administrator. An upgrade path substitutes the Collection Pages for Content Pages with a collection display without any functional change.

What Changed?

Previously, some Modification Conflicts and all Modification Deletion conflicts required manual resolution. These cases would show up in the Checking Changes screen, requiring manual user action to be resolved. They are now automatically resolved by overwriting production with the changes made in the publication and won't be displayed in the Checking Changes screen.

Why Was This Change Made?

The previous behavior required users to manually address many types of conflicts, which was usually a time-consuming effort. The new behavior reduces the friction in the publishing process while guaranteeing publications’ users they will be able to publish the needed modifications.

Who Is Affected?
All publication users are affected, but the focus is on the ones responsible for solving the conflicts and publishing the content.

How Should I Update My Features or Implementation to Better Adopt the Breaking Change?

Consider that now Publications’s users have more power to overwrite production changes. If you understand that the end-user scenario still requires human verification in Modification Deletion cases, the previous behavior can be restored by using the Modification Deletion Conflicts Toggle on Instance Settings > Publications.