2024.Q2 リリース以降、Portalのランタイムには Java 17 または 21 がすでに必要ですが、ソースコードはJava 8でもコンパイルできました。2025.Q1 リリースでは、コンパイルに Java 17 または 21 も必要になります。

ヘッドレス APIを使用してテキスト・フィールドに対してGETを実行し、その結果コンテンツが空になった場合、出力がスキップされる代わりに ”” が返されます。この変更により、各ユーザーが情報を使って何をするか、より柔軟に決めることができるようになりました。

ユーザーは、この変更に対応するために、テキストフィールドに対するすべてのGETリクエストを見直してください。

現在、ユーザーが任意のエンティティをインポートするためにBatchを呼び出すと、返されるエラーはRest APIへの通常の呼び出しとは異なるストラクチャを持ちます。具体的には、「failedItems」情報に関連する構造が異なっています。

この変更により、ユーザーはどのエンドポイントを使用していても同じストラクチャ化された情報を持つことになるので、エラーのマッチングやUIでの表示はよりシンプルになります。

主な変更点:

現在のストラクチャ:

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

新しいストラクチャ:

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

• 「更新」権限の付与: ロールに「更新」権限を付与することで、ユーザはフォルダの名前や説明などのプロパティを編集できるようになります。

• 「詳細な更新」権限の付与: ロールに 「詳細な更新」権限を付与することで、ユーザーはフォルダに関連付けられたワークフローを更新できます。名前や説明フィールドなどのフォルダのプロパティは、無効のままでの編集はできません。

• Webコンテンツまたはフォルダを購読しているユーザーは、ワークフローのレビュープロセスに直接関与していない限り、保留状態のアセットに関する通知を受信しません。

• この変更は、ドキュメントとメディアの現在の動作に合わせるためのものです。

ユーザーがAnalytics Cloudで削除されると、永久に削除される前にまず抑制されます。 その結果、ユーザーごとに2つのリクエスト（抑制と削除）が表示されます。

以前は、各ユーザーの削除には2つの別々のリクエストが発生していました。 現在では、すべてのユーザーが1つの抑制および削除リクエストにグループ化され、リクエスト数が減少しています。 たとえば、各リクエストには、ユーザーごとに個別のリクエストを生成する代わりに、影響を受けるすべてのメールアドレスのリストが含まれるようになりました。

Analytics Cloud > Settings > Data Control & Privacy > Request Logで削除ログを確認できます。

何が変わったのか？
新しい一括操作機能により、パブリケーション内の複数の変更を選択して管理できます。 ユーザーは、管理バーから一括して変更を移動または破棄できるようになった。 これにより、大規模なパブリケーションの管理が簡素化される。

なぜこのような変更がなされたのか？
以前は、ユーザーはそれぞれの変更を個別に管理しなければならず、時間がかかっていた。 この変更により、ユーザーの効率が向上し、管理負担が軽減され、大規模なパブリケーションに対してよりスケーラブルなプラットフォームとなった。

新しい行動はユーザーにとって良いことなのか？
時間と労力を大幅に節約し、複数の変更を迅速に管理することが容易になる。 この結果、大量の変更を処理する際に、よりスムーズで迅速なユーザーエクスペリエンスが実現します。

誰が影響を受けるのか？
大規模なパブリケーションを管理したり、複数の変更を処理する必要があるユーザーは、このアップデートの恩恵を受けるだろう。 頻繁に変更箇所を移動したり、破棄したりするユーザーのプロセスを効率化します。

どのように自分の機能や実装を更新すれば、より良いブレークチェンジを採用できるのか？
必要に応じて、この機能は、インスタンス設定 > 機能フラグ > feature.flag.LPS-171364=true または パブリケーションの一括アクション (LPD-20183) の機能フラグで有効/無効にできます。