設計ガイド
設計ガイド
Ragic の各レコードには、それぞれ対応するレコード管理者が設定されています。レコード管理者は、シートのアクセス権限とあわせて、そのユーザーが特定のレコードを閲覧または編集できるかどうかを決定します。
レコード管理者は、レコード単位でアクセス権限を柔軟に拡張したい場合に適しています。たとえば、あるユーザーが所属グループのシートアクセス権限でアンケート式ユーザーに設定されている場合、そのユーザーは自分が作成したレコードのみ作成・編集できます。ほかのユーザーが作成したレコードも編集できるようにしたい場合は、割り当て機能を利用できます。割り当てられたユーザーは、そのレコードのレコード管理者として追加され、対象レコードの閲覧・編集が可能になります。
Ragic では、ユーザーは次の方法でレコードのレコード管理者になることができます。
1. レコード作成者：
レコードを作成して保存したユーザーは、デフォルトでそのレコードのレコード管理者になります。
2. 割り当てられたユーザーまたはグループ：
シート内のユーザー選択フィールドまたはグループ選択フィールドで、選択したユーザー／グループをレコード管理者に設定オプションを有効にすると、選択されたユーザーまたはグループにアクセス権限が付与され、レコード管理者として追加されます。詳細は、こちらの記事をご参照ください。
3. レコード承認者：
承認フローが開始されると、承認が該当ステップに到達した時点で、そのステップの承認者が自動的にレコード管理者として追加され、レコードの管理・編集権限が付与されます。
4. ゲストユーザー：
ゲストユーザーがメールで受け取ったリンクからレコードにアクセスすると、そのゲストユーザーのメールアドレスが自動的にそのレコードのレコード管理者として追加されます。
レコードのレコード管理者になっても、そのレコードに対する完全な権限が付与されるわけではありません。ユーザーが実行できる操作は、引き続きシートのアクセス権限によって制限されます。たとえば、以下のようなケースがあります。
1. シートのアクセス権限がアンケート式ユーザーに設定され、詳細設定で編集不可が有効になっている場合：
ユーザーがそのレコードのレコード管理者になっても、そのレコードは閲覧のみ可能で、編集はできません。
2. シートのアクセス権限が閲覧者または権限なしに設定されている場合：
閲覧のみ： レコード管理者に設定されていても、そのユーザーはそのレコードを閲覧のみ可能で、編集はできません。
権限なし： レコード管理者に設定されていても、そのシートにアクセスする権限自体がないため、そのレコードを閲覧することはできません。
子テーブルから新しいフォームを作成すると、子テーブルの各行は新しいシート上でそれぞれ独立したレコードとして扱われます。
以下では、条件ごとにレコード管理者がどのように設定されるかを例を使って説明します。
例：
1. 「プロジェクト」シート（親シート）があります。
2. このシートには、各プロジェクトタスクを一覧表示する子テーブルがあります。
3. この子テーブルから「タスクリスト」という新しいシートが作成されます（以下、新しいシートとします）。
(1) 親シートでレコードが作成された場合： 子テーブルから新しいフォームを作成した場合、親シートでそのレコードを作成したユーザーが、対応する新しいシート側のレコードのレコード管理者として自動的に設定されます。これは、そのレコードが実質的に同じユーザーによって作成されたものとして扱われるためです。
(2) 新しいシートでレコードが直接作成された場合：
そのレコードを作成したユーザーが、そのままレコード管理者になります。なお、この設定は、親シート側の関連レコードのレコード管理者には影響しません。
子テーブルから新しいシートを作成した後、割り当ての効果は、割り当てフィールドがどこにあるかによって異なります。以下では、よくある 3 つのケースを紹介します。
| 割り当てフィールドの場所 | 新しいシートでレコード管理者として設定されるレコードの範囲 |
|---|---|
| 1. 親シートの独立フィールド（「プロジェクトリーダー」） | その親シートの子テーブルから作成された新しいシート内のすべてのレコード |
| 2. 親シートの子テーブルフィールド（「タスク担当者」） | 該当する子テーブル行から作成された新しいシート内の該当レコードのみ |
| 3. 新しいシートの独立フィールド（「タスク担当者」） | その新しいシート内の該当レコードのみ |
補足：
(1) 親シートにアクセスできるユーザーを、新しいシートでレコード作成時にも自動的にレコード管理者にしたい場合は、元フォームのフィールドを新規作成機能を使って、親シートの割り当てフィールド（「プロジェクトリーダー」）を新しいシートに追加してください。これにより、親シートで割り当てられていたユーザー情報が引き継がれ、新しいシートでもレコード管理者として設定されます。
(2) 新しいシートで直接作成されたレコードについては、親シートで割り当てられているユーザーがそのままレコード管理者になるわけではありません。ただし、親シートの独立フィールド（「プロジェクトリーダー」）で割り当てを更新または再適用すると、それらの新規レコードのレコード管理者もあわせて更新されます。
(1) 親シートから承認フローを開始した場合： 承認者は、親シートのレコードと、それに対応する新しいシート上のレコードの両方で、レコード管理者になります。
(2) 新しいシートから承認フローを開始した場合：
承認者は、その新しいシート上の該当レコードのみのレコード管理者になります。
ゲストユーザーの権限は、独立フィールドでのみ有効になり、対応するレコードのレコード管理者として追加されます。子テーブル内のゲストフィールドを使用しても、対応するレコードのレコード管理者には影響しません。
(1) 親シートの独立ゲストフィールドから権限が付与された場合：
ゲストユーザーは、親シートの該当レコードのみのレコード管理者になります。
(2) 新しいシートの独立ゲストフィールドから権限が付与された場合：
ゲストユーザーは、新しいシートの該当レコードのみのレコード管理者になります。
ユーザーのレコード管理者権限を解除したい場合は、以下の方法を利用できます。
1. 割り当てフィールドの値を削除する：
権限が割り当てによって付与されている場合は、そのレコード内の割り当てフィールドからユーザーまたはグループの値を削除してください。保存後、システムは自動的にそのユーザーまたはグループのレコード管理者権限を解除します。
2. 一括編集で解除する：
一括編集を使って割り当てフィールドの値をクリアするか、複数のレコードから特定のレコード管理者をまとめて直接削除できます。
3. 手動で解除する：
レコード右下の情報iウィンドウで、ユーザー名またはグループ名の横にあるxをクリックすると、その管理権限を解除できます。ただし、必要な場合を除き、手動での解除は推奨されません。実際のレコード管理者とレコード履歴の内容に差異が生じる可能性があるためです。
1. 設計モードで、割り当てフィールドをユーザーフィールドまたはグループフィールドに変更した場合（選択したユーザー／グループをレコード管理者に設定オプションを無効にした場合）、既存レコードのレコード管理者一覧には影響しません。
2. 設計モードで、独立したメールフィールドのゲストユーザー用メール認証オプションを有効または無効にしても、既存レコードのレコード管理者一覧は自動では更新されません。
1. 一括更新（割り当てフィールド、ゲストユーザーフィールドの変更、またはレコード管理者の削除を含む）を実行した後に、変更を復元した場合、システムが更新するのは親シートのレコード管理者のみです。子テーブルから新しいフォームを作成によって生成された新しいシート側のレコード管理者は同期されません。
2. ゲストユーザーフィールドに対して一括更新を行った後、変更を復元しても、すでにレコード管理者として追加されているゲストユーザーは削除されません。
1. レコードの承認フローが取り消された場合でも、承認フローによってレコード管理者として追加されたユーザーは自動的には削除されません。
2. 独立したゲストフィールドの値を手動で削除しても、すでにレコード管理者として追加されているゲストユーザーは、レコード管理者一覧から削除されません。
貴重なご意見をありがとうございます！
