カスタムオブジェクト

実行時にオブジェクトとフィールドを追加する方法。モジュールが制御するもの、拒否されるキー、上限、そしてリレーションが関連リストを生む仕組みです。

custom_objects モジュールは、ワークスペースが 14 個の標準オブジェクトと並べて独自のオブジェクトとフィールドを追加できるようにします。それ以外は標準と同じです。同じフィールドの種類、同じレコードのエンドポイント、同じ権限の検査です。

モジュールが制御するのはスキーマであり、データではありません。 オブジェクトやフィールドの作成には必要ですが、レコードの読み書きには一切不要です。カスタムオブジェクトでも標準オブジェクトでも同じなので、データを動かすだけのクライアントはモジュールの状態に関係なく動きます。

オブジェクトの作成

POST /objects は 3 つを取ります。

2 種類のキーが object_key_reserved で拒否されます。標準オブジェクトのキーと、プラットフォームが内部で使う名前に衝突するキーです。汎用的な語ではなく、その製品が所有する語を選んでください。

オブジェクトの変更

PATCH /objects/{objectId} は key、label、singularLabel、そして読み取り時の revision を受け付けます。

オブジェクトのキーは変更できます。フィールドのキーはできません。 オブジェクトのキーの変更は通りますが、古いキーを指していたすべてのパスと保存済みフィルターは一致しなくなるため、無料の変更ではありません。フィールドは逆です。更新エンドポイントは key、type、targetObjectId を受け付けますが、そのどれも変更は拒否します（field_key_immutable、field_type_immutable、field_target_immutable）。実際に動くのは label と required だけです。

required を有効にする変更は、その値を持たないレコードが 1 件でもあれば拒否されます。標準フィールドの required は一切変更できません（field_system_locked）。仮想の種類は必須にできません。何も書き込まないからです。

フィールド

フィールドは POST /objects/{objectId}/fields で追加し、標準オブジェクトが使うのと同じ 19 種類が使えます。

1 つのオブジェクトが持てるフィールドは最大 256 個です。 257 個目は object_field_limit で拒否されます。

すべてのオブジェクトのテーブルが持つ列として 10 個のキーが予約されており、フィールドはそのいずれも使えません。

id · name · organization_id · object_id · revision · created_at · updated_at · archived_at · created_by · updated_by

これを使うと field_key_reserved が返り、そのオブジェクトに既にあるキーを再利用すると field_key_taken が返ります。

リレーションが関連リストを生む

relation フィールドは指し先のオブジェクトを指定します。逆方向は反対側から読み取ります。GET /objects/{objectId}/related はリレーションフィールドがこのオブジェクトを指しているオブジェクトを返し、これが関連リストの元になります。

つまりカスタムオブジェクトは、どこかに登録することではなく標準オブジェクトを指すことで、その文脈に現れます。自分のオブジェクトから account へリレーションを追加すれば、取引先に自分のレコードの関連リストが増えます。

変わらないこと

カスタムオブジェクトのレコードは標準オブジェクトと同じエンドポイント（/objects/{objectId}/records など）を使い、同じ 4 つの権限検査を通ります。カスタムデータ専用のスコープはありません。records.read と records.write がワークスペースの持つすべてのオブジェクトをカバーします。