チュートリアル: Studio プロジェクトワークフローの開始

ユーザーを プロジェクト に追加すると、アクセスが許可されるか（参加者のアクセスを制限するように設定された プロジェクト の場合）、またはアクセスが拒否されます（参加者のアクセスを制限するように設定されていない プロジェクト の場合）。制限された参加者のアクセスについては、以下で詳しく説明します。

プロジェクト にユーザーを追加するには、以下の手順に従ってください。

1. プロジェクト内で、プロジェクトタブの プロジェクトの設定 を選択します。プロジェクトの設定ダイアログが表示されます。

2. [ユーザーアクセス] タブを選択します。以前に追加されたユーザーがリストに表示されます。

3. 新しい個々のユーザーを追加するには、 を選択します。[メールアドレスの追加] ダイアログで、ユーザーのメールアドレスを入力し、[OK] を選択します。
4. グループ にユーザーを追加するには、 をクリックします。[グループの選択] ダイアログで目的のグループを選択し、[OK] を選択します。そのグループ内のすべてのユーザーが自動的に追加されます。
   プロジェクトの建物所有者のみが、グループを使用してプロジェクトにユーザーを追加できます。
5. デフォルトでは、 ユーザー アクセス タブに追加されたすべてのユーザーの アクセス が自動的に 許可 に設定されます。特定のユーザー（この特定の プロジェクト へのアクセス権を持たないべき グループ によって追加されたユーザーなど）へのアクセスをブロックするには、目的のユーザーを選択し、 ブロック を選択します。 ブロックされたユーザー ダイアログが表示されます。デフォルトのオプションである アクセスをブロック（元に戻すことが可能）— このユーザーは後から再招待できます を選択したままにし、 1 人のユーザーをブロック を選択します。
6. このプロジェクトへのアクセスを、ユーザー アクセスタブにリストされているユーザーのうち、アクセスが許可に設定されているユーザーのみに制限するには、このプロジェクトを非公開にするを選択します。

   この設定とユーザーのアクセスステータス（許可済みまたはブロック済み）の関係により、「ホワイトリスト」または「ブラックリスト」に相当する設定を行うことができるため、いくつか詳細な説明が必要です。

   • このプロジェクトを非公開にするが選択されている場合、ユーザーアクセスタブにリストされているユーザーのうち、アクセスが許可に設定されているユーザーのみがこのプロジェクトにアクセスできるようになります。これは「ホワイトリスト」に相当します。
   • このプロジェクトを非公開にする が選択されていない場合、ここで「 ユーザーアクセス 」タブの一覧に登録されているユーザーのうち、 アクセス が ブロック に設定されているユーザーを除き、すべてのユーザーがこの Project にアクセスできます。これは、いわゆる「ブラックリスト」と同等です。
7. 選択 OK.
   

権限は、ユーザーがプロジェクト内で実行できるアクションを定義します。権限は、個々のユーザーだけでなくグループに対しても定義できます。

1. プロジェクト内で、プロジェクトタブの プロジェクトの設定 を選択します。プロジェクトの設定ダイアログが表示されます。

2. [権限] タブを選択します。

   デフォルトのグループである参加者と、以前に追加されたその他のユーザーまたはグループが表示されます。参加者グループはプロジェクト内のすべてのユーザーに適用され、初期権限設定はプロジェクトの作成時に構成されます。このグループは削除できません。プロジェクトの作成時、参加者グループのほとんどの権限はブロックに設定されます。参加者グループにより広範なアクセスを許可するのではなく、特定のユーザーやグループに追加の権限を付与することが推奨されます。
   

3. 個々のユーザーまたは [グループ] を追加するには：
   1. 選択 .

   2. [ユーザー/グループの追加] ダイアログで、目的のユーザーまたはグループを選択し、[OK] を選択します。プロジェクトで使用できるのは建物所有者のグループのみであるため、建物所有者のグループのみが表示されます。デフォルトでは、ユーザーやグループが追加されると、それらは [参加者] グループの権限を継承します。

      あなたがプロジェクトの建物所有者で、このプロジェクト用に新しいグループを作成したり、現在使用されているグループのメンバーシップを変更したりする場合は、[グループの管理] を選択します。グループの作成と管理の詳細については、Studio グループ を参照してください。フル制御権限を持つユーザーは [グループの管理] を使用して独自のグループを管理することもできますが、それらのグループをこのプロジェクトで使用したり、建物所有者のグループを変更したりすることはできません。

      グループを作成する際は、Revu では同じセッションまたはプロジェクト内でユーザーが複数のグループに所属できることに留意してください。その場合、そのユーザーの権限は、最も制限の厳しいグループの権限が適用されます。そのため、すでにグループに属しているユーザーを別のグループに追加しても、期待通りの効果が得られない場合があります。これは、最初のグループの権限がより制限されているために予期した権限が付与されなかったり、2番目のグループの権限がより制限されているために意図しない制限が課されたりするためです。

4. ユーザーまたは グループ の権限を変更するには：
   1. [ユーザー/グループ] リストで、目的のユーザーまたはグループを選択します。
   2. [適用される権限] リストで目的の権限を選択します。
   3. ドロップダウンリストから権限設定を選択します。
      • 参加者グループの権限を設定する場合、選択肢はブロックまたは許可です。
      • すべての他のユーザーおよびグループの権限を定義する場合、オプションは空欄、ブロック、または許可になります。空欄を選択すると、ユーザーまたはグループは出席者グループに定義された権限を継承します。
      • フル コントロール権限は強力であり、これを許可に設定すると、ユーザーまたはユーザー グループに管理者権限が付与されます。これによる影響は次のとおりです。
        • 管理者のすべての権限は許可に設定されています。
        • 管理者はプロジェクトの名前を変更できます。
        • 管理者はプロジェクトを削除できます。
        • 管理者は [ユーザーアクセス] を管理できます。
        • 管理者は、他のユーザーの権限を管理できます。
        • 管理者は、フォルダーのデフォルト権限に関係なく、どのフォルダーに対してもフル権限を持ちます。

        ただし、管理者が実行できる操作にはいくつかの制限があります：

        • 管理者はホストをブロックできません。
        • 管理者は、ホスト（または他の管理者）の グループ にアクセスできません。
5. ユーザーまたはグループを削除するには、それらを選択して を選択します。
6. [OK] を選択します。

権限を設定する際には、留意すべき2つの階層セット（権限セットと権限状態）があります。

• [権限セット] は、ユーザーがどのようにして権限を持つようになったかを説明します。ユーザーに個別に割り当てられましたか（個別権限）？それとも、ユーザーは特定のグループに属しているために権限を取得しましたか（グループ権限）？あるいは、上記の2つの条件のどちらも満たされなかったため、ユーザーはデフォルトで一般的な権限になりましたか（一般権限）？
• Permission State は、ユーザーが特定のタスクの実行を許可されているか（Allowed）、許可されていないか（Blocked）を示します。個々のユーザーやグループの場合、パーミッション状態は個別選択（Explicit）するか、あるいは空白のままにして Everyone グループの対応するパーミッション状態をデフォルトとして継承（Inherited）させることができます。

権限状態は Permission Sets 内で機能し、一般的にはユーザーが競合する権限を持つ 2 つ以上のグループに所属している場合に発生する競合を解決するためにのみ使用されます（詳細は以下の例 4 および 5 を参照してください）。通常、ユーザーを複数のグループに追加しないことが推奨されますが、必要な場合は、ホストと管理者が連携して適切な権限が付与されるようにしてください。

階層

階層は以下の通りです：

権限セット

1. 個別の権限 (特定のユーザーに対して設定された権限) が最優先されます。
2. グループ権限（つまり、作成したグループに対して設定された権限）は、二次的な重要性を持ちます。
3. 一般的な権限（つまり、デフォルトの「Everyone」グループに設定された権限）の優先度は最も低くなります。

権限の状態

1. 「明示的ブロック」（つまり「ブロック」に明示的に設定された権限）は最優先されます。
2. 「明示的な許可」（つまり「許可」に特別に設定された権限）は二次的な重要度を持ちます。
3. 継承された状態（デフォルトのEveryoneグループから継承された、ブロックまたは許可のいずれかの権限）の優先順位が最も低くなります。

例

これらの階層を念頭に置いて、ユーザーの実際の権限がどのように決定されるかを示す例をいくつか挙げます。

1. ユーザー Alice に個別の権限が設定されており、「招待の送信」権限が ブロック済み に設定されています。また、ユーザー Alice はグループ A にも所属しており、グループ A の「招待の送信」の権限は 許可済み に設定されています。Alice は プロジェクト への招待を送信することが できません 。
   • 彼女の個別の権限は、グループ A の権限よりも優先されます。
2. ユーザー Bob には個別の権限が設定されており、「招待の送信」権限は 許可 に設定されています。また、ユーザー Bob はグループ A にも所属しており、グループ A における「招待の送信」権限は ブロック に設定されています。Bob は プロジェクト への招待を送信することが できます 。
   • 個人の権限は、グループ A の権限よりも優先されます。
3. ユーザーのCharlieには個別権限が設定されており、「招待の送信」権限は 許可 に設定されています。ユーザーのCharlieはグループAにも所属しており、グループAの「招待の送信」権限は<blank> に設定されています。「全員」グループの「招待の送信」権限は ブロック に設定されています。Charlieは プロジェクト に招待を 送信できます 。
   • 個人の権限は、グループ A の権限よりも優先されます。
4. ユーザー Alice には個別の権限が設定されていませんが、招待の送信権限が 許可 に設定されているグループ A と、招待の送信権限が ブロック に設定されているグループ B の両方に所属しています。Alice は プロジェクト への招待を送信することが できません 。
   • グループ B の明示的なブロックされた権限は、グループ A の明示的な許可された権限よりも優先されます。
5. ユーザーのBobには個別の権限が設定されていませんが、「招待の送信」権限が <blank>許可 に設定されているグループAと、「招待の送信」権限が に設定されているグループBのメンバーです。「Everyone」グループの「招待の送信」権限は ブロック に設定されています。Bobは プロジェクト への招待を送信する ことができます 。
   • グループAによる明示的なAllowed（許可）権限は、グループBからの継承されたBlocked（ブロック）権限よりも優先されます。