新機能
複数のデータソースのサポート
「データソースマネージャー」プラグインが追加され、すべてのデータソースのコレクションとフィールドを管理します。データソースマネージャープラグインは、データソース管理のための集中化されたインターフェースを提供しますが、データソースにアクセスする機能は提供していません。さまざまなデータソースプラグインと併用する必要があります。現在サポートされているデータソースは次のとおりです:
- メインデータベース:NocoBaseのメインデータベースで、MySQL、PostgreSQL、SQLiteなどのリレーショナルデータベースをサポートしています。
- 外部MySQLデータソース:既存のMySQLデータベースにデータソースとしてアクセスします。
- 外部MariaDBデータソース:既存のMariaDBデータベースにデータソースとしてアクセスします。
- 外部PostgreSQLデータソース:既存のPostgreSQLデータベースにデータソースとしてアクセスします。
その他、API(SDK)を提供するプラットフォームや一般的なデータベースタイプも拡張が可能です。

コレクション管理の調整
元々の「コレクションマネージャー」を「データソース > メインデータベース > 設定」に移動しました。

非IDフィールドを主キーおよびリレーション制約としてサポート
コレクションを作成する際に、IDフィールドを作成しない選択ができます。

整数フィールドを主キーとして使用できます。

単一行テキストフィールドも主キーとして使用できます。

リレーション制約は、非主キーのフィールドとして設定されたユニークインデックスを持つ他のフィールドを選択することをサポートします。

ドラッグ&ドロップソートの調整
「ソート」タイプのフィールドが追加され、コレクションを作成する際に、ソートフィールドが自動的に生成されなくなり、手動で作成する必要があります。

フィールドをグループとして選択した場合、ソートの前にグループ化が行われます。

テーブルブロックでのドラッグ&ドロップソートを有効にする場合、ソートフィールドを選択する必要があります。

カンバンブロックを作成する際にもソートフィールドを選択する必要があります。

ユーザーと権限インターフェースの調整
ユーザー管理インターフェースが追加され、ユーザーと役割の管理が1つのメニューに統一されました。

役割管理インターフェースが調整され、ユーザーに関連付けられた役割、権限、部署などの管理を容易にしました。

元の「アクション権限」を「データソース」タブに移動しました。

部署プラグイン

ユーザーを部署で整理し、階層関係を設定して役割をリンクし、権限を管理し、ワークフローや式の変数として部署を使用します。
ワークフロー:承認
承認プラグインは、このプロセスのための専用ワークフロータイプ(トリガー)「承認を開始」と「承認」ノードを提供します。NocoBaseの独自のカスタムデータテーブルとカスタムブロックと組み合わせることで、さまざまな承認シナリオを迅速かつ柔軟に作成・管理できます。
承認設定

承認プロセス

詳細はドキュメンテーションを参照してください:ワークフロー承認
ワークフロー:プロセス終了ノード
このノードが実行されると、現在のワークフローの実行が直ちに終了し、ノードで設定されたステータスで終了します。このノードは通常、特定のロジックフローの制御に使用され、特定の論理条件を満たした後、現在のワークフローを終了し、その後の処理を続行しません。これはプログラミング言語のreturnコマンドのようなもので、現在実行中の関数を終了します。

詳細はドキュメンテーションを参照してください:プロセス終了ノード
ワークフロー:カスタム変数ノード
ワークフロー内で変数を宣言したり、以前に宣言した変数に値を割り当てたりすることができ、通常はワークフロー内で一時データを保存するために使用されます。このノードは、計算結果を分岐外で後で使用するために保存する必要があるシナリオ(ループ、並行実行など)に適しています。

詳細はドキュメンテーションを参照してください:カスタム変数ノード
ワークフロー:リクエストインターセプター
リクエストインターセプタープラグインは、フォームの操作に対してリクエストをインターセプトするメカニズムを提供します。インターセプトイベントは、対応するフォーム操作が送信された後、処理される前にトリガーされます。トリガー後のフロー内で「プロセス終了」ノードが実行される場合、または他のノードが実行に失敗(エラーやその他の未実行の状態)した場合、そのフォーム操作はインターセプトされ、そうでない場合は予定された操作が正常に実行されます。これは、ビジネス検証やロジックチェックを行い、クライアントが送信した作成、更新、削除の操作を承認またはインターセプトするために使用できます。

詳細はドキュメンテーションを参照してください:リクエストインターセプター
ワークフロー:レスポンスメッセージノード
レスポンスメッセージノードは、特定のタイプのワークフロー(リクエストインターセプトやフォームイベントなど)で、クライアントにカスタムメッセージでフィードバックを提供します。
ノード設定

プロンプトメッセージ

詳細はドキュメンテーションを参照してください:レスポンスメッセージノード
非互換の変更
名前の衝突するAPI
このカーネルの変更では、新しいバージョンのAPIが古いバージョンの名前と衝突します。これらの衝突する古いバージョンのAPIは、このバージョンで保持されますが、統一的に_deprecatedの接尾辞が付けられます。
| 元のAPI | 廃止されたAPI | 新しいAPI |
|---|---|---|
| CollectionProvider | CollectionProvider_deprecated | CollectionProvider |
| useCollection | useCollection_deprecated | useCollection |
| useCollectionField | useCollectionField_deprecated | useCollectionField |
| useCollectionManager | useCollectionManager_deprecated | useCollectionManager |
| useContext(CollectionManagerContext) | useCollectionManager_deprecated | useCollectionManager |
上記の関連APIを使用している場合、次の2つの方法で変更できます:
- 簡単な置換:元のAPIを
_deprecatedのついたものに置き換えます。たとえば、useCollection()をuseRecord_deprecated()に置き換えます。 - 新しいドキュメントに従って新しいAPIを使用します:新しいAPIの名前は古いAPIと同じですが、パラメータや返り値に違いがありますので、新しいドキュメントを参照して、対応するコードを調整してください。
調整が必要な他のAPI
registerTemplate()はapp.dataSourceManager.addCollectionTemplates()に変更されました。registerField()はapp.dataSourceManager.addFieldInterfaces()に変更されました。registerGroup()はapp.dataSourceManager.addFieldInterfaceGroups()に変更されました。useContext(CollectionManagerContext)はuseCollectionManager_deprecated()に変更されました。ExtendCollectionsProviderを使用してコレクションを拡張します。RecordProviderは必要に応じて親パラメータの明示的な渡しが必要です。