オブジェクト間の1対1の関係によりワークフローを合理化する新機能を導入しました。ユーザーは、プライマリオブジェクトのCRUDビューから直接ネストされたオブジェクトを作成および更新できるようになり、データ セットマネージャー (DSM) から変換されたシームレスな削除および表示操作を利用できるようになりました。このアップデートにより、データ管理がよりスムーズかつ効率的になりました。

ユーザーが、フラグメントおよびコレクション表示ですでに定義済みのWebコンテンツのストラクチャの反復可能なフィールドをマッピングできるようになりました。

/search と /suggestions のAPIには、次の機能強化が加えられています:

• /searchのサイト (グループ) ID と外部参照コード (ERC) をサポートする新しいオプションの scope パラメーターが追加されました。/suggestionsのscopeパラメーターも、同じセマンティクスを持つように更新されました。

• /search は現在 RELEASE ステータスです。

• APIは現在、/o/search/v1.0/ エンドポイント下で利用可能で、サーバー側の転送を介した呼び出しによる現行の /o/portal-search-rest/v1.0 呼び出しの後方互換性があります。

詳細はドキュメントをご参照ください。

Elasticsearch 8.15.x がテストされ、対応するLiferayのバージョンとの互換性マトリックスに追加されました。

注意: Elasticsearchの新しいマイナーバージョンとの互換性は、2つの方法でテストされています:

1. 最新-最新: 最新の利用可能な Elasticsearchのマイナーバージョンを使用して、最新のLiferayバージョンをテスト → 例: Master/2024.Q3 + Elasticsearch 8.15

2. ミニマム-最新: Elasticsearch 8の互換性が最初に利用可能になったミニマムのLiferayバージョンを、Elasticsearchの最新のマイナーバージョンでテスト → DXP 7.4 U81/DXP 7.3 U31 + Elasticsearch 8.15

このようにすることで、Liferayはより広範なデプロイメントのベースが最新の検索エンジンバージョンでスタックを運用できるようになります。

Elasticsearchは通常、およそ 2 か月ごとに新しいマイナー バージョンをリリースするため、これは定期的なプロセスであり、四半期ごとに計画されたアクティビティです。

Elastic’s product lifecycle に従い、Elasticsearch 7.17.xバージョンはElasticsearchバージョン9がリリースされるまでサポートおよび保守されます。 Elasticsearch 9.0.0は、2025年初頭にリリースされる予定です。

したがって、Liferayでは、7.17.x をデプロイメントしているすべてのお客様に対し、互換性のある最新の Elasticsearch 8.x バージョンへのアップグレードプロジェクトの計画段階を開始することを強くお勧めします。

Elasticsearch 8との互換性は7.4 U81+で利用可能です。→ Operating Liferay 7.4 GA/Update 81+ with Elasticsearch 8 - Liferay

注意: Elasticsearch 8.x との互換性は、バンドルされている Elasticsearch 7 コネクタと Elasticsearch 8 の REST API Compatibility によって提供されます。

Liferayには、クライアントバージョンとして7.17.21を使用し、また開発・テスト用にSidecar ElasticsearchサーバーのバージョンとしてアップデートされたElasticsearchコネクターが同梱されています。

条件コントリビューターの設定は、より小さなフットプリントでブループリントのJSON 内に保存されるようになり、デフォルトの設定（すべてのコントリビューターを有効化 → Enable All）または新しい Disable All オプションを使用する場合、ブループリントのサイズが 90% 以上削減されます。

異なるオプションの動作は以下のとおりです:

• Enable All を使用すると、現在および将来プラットフォームに導入されるすべてのクエリの条件コントリビューターが自動的に有効になります。Disable All は逆の動作をします。

• カスタマイズ では、設定は指定されコントリビューターのリストにロックされます。

データセットマネージャーの選択フィルターが改良され、さまざまな種類のソースを選択できるようになりました。候補リストに加えて、管理者ユーザーはフィルター値のソースとしてAPI ヘッドレスを選択できるようになり、フィルター値に API 応答からの値が入力される可能性があります。これにより、ユーザーはフィルタ作成プロセスをより自動化できるようになります。

データセットマネージャーでは、配列ストラクチャをマップできるようになりました。これにより、データ セットの特定のセルに値のリストを表示できます。例えば、ユーザーのロールや製品のタグをリストできます。

ユーザーがフロントエンドデータセットに直面している場合、アイテムはデータ セットマネージャーで設定されたユーザーと対話するためのアクションを表示できます。今後は、ユーザーがアイテムまたは作成アクションを通じて宛先URL に移動すると、現在のURLが宛先ページに追加されるため、ユーザーはアクションをシームレスに実行した後にデータ セットに戻ることができます。

CXフィルターでは、開発者がオンデマンドのビジネスロジックとUIを備えた独自のフィルターを設定し、データセットマネージャーでデータセットに追加して、データセット内のエンドユーザーに使用できます。 この新しい値により、クライアント拡張は汎用的なものになり、同じクライアント拡張機能を使用して、異なるフィールドでフィルタリングするフィルタを設定できます。

ユーザーセッションのレプリケーションがTomcatアプリケーションサーバー用に最適化されました。

ユーザーは、特定の期間内に許可されるゲスト送信の数のリセットを構成できます。

ユーザーは、オブジェクトやワークフローのアクションにおけるスクリプトの悪用を避けるために、必要なセキュリティ・レイヤーを追加できます。

大文字で始まる候補リストを作成できるようになりました。 重要な特徴の1つは、ユーザーがアクティブと非アクティブの値でフィルタリングできるようになったことです。

オブジェクトは幅広いユースケースに使用されますが、その中には他のユースケースよりも技術的なものもあります。この機能を使用すると、ユーザーはオブジェクトをリストする場所を設定できるようになります。したがって、不必要な複雑さが生じ、他のユーザーの認知的負荷が軽減されます。

ユーザーは、ゲストユーザーのロケールを観察し、ゲストユーザーの言語設定に基づいて電子メール通知を送信するようにオブジェクトを設定できるようになりました。

ゲストユーザーの言語設定は、ゲストユーザーがフォーム送信時に使用した言語によって決定されます。 ロケールが決定できない場合、または通知テンプレートが存在しない場合、通知はインスタンスのデフォルト言語で送信されます。

For those Objects that have the translation active, users can not get this entry information using GraphQL. In order to improve GraphQL capabilities, we have exposed the _i18n properties, so any user can retrieve it.

翻訳がアクティブになっているオブジェクトの場合、ユーザーは GraphQL を使用してこのエントリ情報を取得できません。 GraphQL の機能を向上させるために、_i18n プロパティを公開し、どのユーザーでも取得できるようにしました。