何が変わったのか？
パブリケーションのサイズ分類がレビューの変更画面に表示されるようになり、パブリケーションのサイズに基づいてLight、Medium、Largeに分類されるようになりました。 ユーザーが分類の上にカーソルを置くと、ポップオーバーで説明が表示され、パブリケーションサイズがパブリケーションのプロセスに与える潜在的な影響について知ることができます。

なぜこのような変更がなされたのか？
この変更により、ユーザーはパブリケーションの規模を把握しやすくなり、パブリケーションのプロセスをより適切に計画できるようになります。 これは、大きなパブリケーションにより多くの時間を割り当てるようユーザーに促すことで、パフォーマンスの問題を防ぎ、競合を減らすことを目的としています。

新しい行動はユーザーにとって良いことなのか？
この新しい分類は、パブリケーションの複雑さをより明確に把握し、ユーザーが予期せぬ遅延を避けるのに役立つ。 また、ワークフローを積極的に管理することで、よりスムーズな公開プロセスを実現することができます。

誰が影響を受けるのか？
すべてのパブリケーションユーザーが影響を受けますが、複数の変更に対応するユーザーや、Webサイトを公開する際に達成しなければならない締め切りがあるユーザーにより重点を置いています。

どのように自分の機能や実装を更新すれば、より良い重大な変更点を採用できるのか？
必要に応じて、この機能を完全に動作させるには、インスタンス設定 > 機能フラグ > パブリケーションツールバーの追加コンテキスト (LPD-20556) の機能フラグが必要です。

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

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

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

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

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

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

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

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

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

何が変わったのか？
レビュー変更画面にプログレスバーが追加され、公開プロセス中にリアルタイムで視覚的なフィードバックが得られるようになりました。 ユーザーは、公開が開始されるのを待っている間、プログレスバーが表示され、公開プロセスの残り時間を知ることができます。

なぜこのような変更がなされたのか？
以前は、公開プロセスにかかる時間をユーザーが視覚的に示すことはできませんでした。 この変更は、透明性を提供することによって、ユーザーエクスペリエンスを向上させ、ユーザーの期待をよりよく管理できるようになります。

新しい行動はユーザーにとって良いことなのか？
新しいプログレスバーは、明確でリアルタイムのフィードバックを提供することで、ユーザーの満足度を高めます。 これにより、ユーザーはパブリケーションスのケジュールを把握しやすくなり、プロセス中の不安を軽減できます。

誰が影響を受けるのか？
すべてのパブリケーション利用者が影響を受けますが、これまで待ち時間が不明瞭であった大規模なパブリケーションや複雑なパブリケーションを扱う利用者に焦点が当てられています。

どのように自分の機能や実装を更新すれば、より良い重大な変更点を採用できるのか？
現在のプロセスに変更は必要ありません。

AMDローダーは削除されました。 Liferay DXPはJavaScriptの公式標準モジュールシステムであるESMを公式にサポートしていますが、AMDはサードパーティ製のソリューションでした。 ESMを採用することで、製品はその言語固有の能力と将来の方向性に合致します。 最近のブラウザはESMをネイティブにサポートしており、トランスパイルや追加のローダーなしで直接使用できます。 これにより、バンドルサイズの縮小、初期ページロードの高速化、開発ワークフローの簡素化が可能になります。

amd-loader を使用しているユーザーは、Liferay.loader に移行する必要があります。詳細は リンク をご参照ください。

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

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

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

（ページの）レイアウトの permissions.view.dynamic.inheritance プロパティが変更されました。他のすべてのモデルでプロパティがどのように機能するかに合わせるためのロジック:

1. 現在はVIEWアクションにのみ適用されます。

2. 現在は制限されています: あるページにVIEWアクセスするためには、ユーザーはその特定のページとそのすべての祖先ページのVIEW権限を持っていなければなりません。

LRDOCS-15042

Ehcache 2.xは、Javaコミュニティによって公式にメンテナンスされなくなりました。DXPの内部キャッシュをEhcache 3.10.8に移行しました。

つまり、既存のehcache設定 xml ファイルは直接互換性がなく、新しい3.x環境でエラーや予期せぬ動作を引き起こす可能性が高いということです。 ユーザーはこれらの設定を見直し、新しい3.xスキーマに従って書き換える必要があります。

コレクションページがページ管理者から削除されました。

ドキュメンテーション: LRDOCS-14626: Documentation LPD-45659 - Remove Collection Pages from page administratorClosed

フラグメントは、コレクションディスプレイの最初のアイテムにのみドロップしてマッピングできます。

ページのSEO設定は、DDMから標準フォームに移動しました。