Studio セッションでのアクセスと権限を定義する
Studioでは、特定のセッションへのユーザーのアクセスを許可または拒否したり、それらのセッションでユーザーが実行できる操作を定義したりできます。 ユーザーがセッションに参加する前、あるいはStudioアカウントを設定する前でも、個々のユーザーまたはユーザーグループに対する権限を定義して設定できます。
セッションは、特定の日付で有効期限が切れるように設定することもできます。
Studio セッションに有効期限を設定できます。この日付は、セッションの作成時に設定するか、後で設定することができます。有効期限を設定した後は、必要に応じて変更できます。
有効期限を設定または変更するには:
-
セッション中は、
[セッションの設定] を選択します。 - 有効期限がすでに設定されている場合は、有効が選択されます。
- 有効期限を無効にするには、有効のチェックを外します。
- 有効期限の日時を変更するには、[有効] の右側にある適切な値を変更します。
- 現在有効期限が設定されていない場合は、[有効] を選択し、右側の現場に目的の有効期限を入力することで設定できます。
- [OK] を選択します。
Revu からホストと参加者に対し、セッションの有効期限が近づくとメール通知が送信されます。以下の日に通知が送信されます。
- 有効期限の7日前
- 有効期限の2日前
- 有効期限の24時間前
- セッションの有効期限が切れた後
同様に、セッションの有効期限が変更されると、通知が送信されます。
ユーザーをセッションに追加すると、そのセッションがプライベートアクセスに設定されているかどうかによって異なる影響が生じます。この セッション を非公開にするが有効な場合、ユーザーを追加することがアクセス権を付与する唯一の方法となります。逆に、この セッション を非公開にするが有効になっていない場合、ユーザーを追加することがアクセスをブロックする唯一の方法となります。プライベートユーザーアクセスについては、以下で詳しく説明します。
ユーザーをセッションに追加しても、そのユーザーにセッションに参加するための招待メールは送信されません。また、これは一度に1人ずつ、メールアドレスによってのみ行われます。数人の新しいユーザーを招待したり、追加中に招待を送信したりするには、「セッションへのユーザーの招待」を参照してください。
セッションにユーザーを追加するには、以下の手順に従ってください:
-
セッション内では、
セッションの設定を選択します。 -
[参加者] タブを選択します。以前に追加されたユーザーがリストに表示されます。
- 新しい個々のユーザーを追加するには、
を選択します。[メールアドレスの追加] ダイアログで、ユーザーのメールアドレスを入力し、[OK] を選択します。 - グループ にユーザーを追加するには、
をクリックします。[グループの選択] ダイアログで目的のグループを選択し、[OK] を選択します。そのグループ内のすべてのユーザーが自動的に追加されます。セッションの建物所有者とフル制御権限を持つユーザーだけが、グループを使用してセッションにユーザーを追加できます。ただし、ここに表示されるグループは、セッション建物所有者のグループのみである点にご注意ください。フル制御権限を持つユーザーは建物所有者のグループを使用してユーザーを追加できますが、自分のグループを使用することはできず、建物所有者のグループのユーザーを変更することもできません。 - デフォルトでは、[ユーザー アクセス] タブに追加されたすべてのユーザーのアクセスは自動的に[許可]に設定されます。特定のエンドユーザーへのアクセスを拒否するには(例:この特定のセッションへのアクセス権を持たないべきグループに含まれているユーザーなど)、該当するユーザーを選択して[ブロック]を選択します。Block ユーザー ダイアログが表示されます。デフォルトのオプションである Block access (reversible) - you can re-invite this ユーザー later を選択したまま、Block 1 ユーザー を選択します。
- セッションへのアクセスを、ユーザーアクセス タブに記載されているユーザーのうちアクセスが許可に設定されているユーザーのみに制限するには、ブロックを選択します。
この設定とユーザーのアクセスステータス([許可] または [ブロック])との関係により、「ホワイトリスト」または「ブラックリスト」と同等のものを設定できるため、これについてさらに説明する価値があります。
- このセッションをプライベートにするが選択されている場合、ユーザーアクセス タブに記載されているユーザーのうち、アクセスが許可に設定されているユーザーのみがこのセッションにアクセスできます。これは「ホワイトリスト」に相当します。
- このセッションをプライベートにするが選択されていない場合、ユーザーアクセス タブに記載されているユーザーのうち、アクセスがブロックに設定されているユーザーを除き、すべてのユーザーがセッションにアクセスできます。これは「ブラックリスト」に相当します。
- 選択 OK.
-
セッション中は、
[セッションの設定] を選択します。 -
[セッションの設定] ダイアログから、[権限] タブを選択します。
セッション 内の全ユーザーに適用される「参加者」グループがデフォルトで表示されます。このグループのほとんどの権限は「許可する」に初期設定されています。参加者グループへのアクセスを許可するのではなく、特定のユーザーまたはグループに追加の権限を付与することをお勧めします。「参加者」グループは、セッション内の全ユーザーに適用され、その初期権限設定はセッションの作成時に構成されます。削除することはできません。セッション 作成時には、「参加者」グループの基本権限は「許可する」に設定されます。推奨されるベストプラクティスは、参加者グループに広いアクセス権を与えるのではなく、ドキュメントの追加やフル制御などの追加の権限を特定のユーザーとグループに与えることです。
- 個々のユーザーまたは [グループ] を追加するには:
- 選択
. [ユーザー/グループの追加] ダイアログで、目的のユーザーまたはグループを選択し、[OK] を選択します。セッションで使用できるのは建物所有者のグループのみであるため、それらのグループのみが表示されます。デフォルトでは、ユーザーやグループが追加されると、それらは [参加者] グループの権限を継承します。
あなたが セッション 建物所有者で、このセッション用に新しいグループを作成したり、現在使用されているグループのメンバーシップを変更したりする場合は、
グループの管理 を選択します。グループの作成と管理の詳細については、Studio グループを参照してください。フル制御権限を持つユーザーはグループの管理を使用して自身のグループを管理することもできますが、それらのグループをこの セッションで使用することはできず、建物所有者のグループ内のユーザーを変更することもできません。グループを作成する際、Revu では、同一のセッションまたはプロジェクト内の複数のグループにユーザーが参加できるようになっていることに留意してください。この場合、そのユーザーの権限は、最も制限の厳しいものがデフォルトとなります。そのため、すでにグループに参加しているユーザーを別のグループに追加すると、予期した権限が付与されなかったり(最初のグループの権限の方が制限が厳しいため)、意図しない制限が課されたりする(2番目のグループの権限の方が制限が厳しいため)、という望ましくない結果になる可能性があります。
- 選択
- ユーザーまたは グループ の権限を変更するには:
- [ユーザー/グループ] リストで、目的のユーザーまたはグループを選択します。
- [適用される権限] リストで目的の権限を選択します。
- ドロップダウンリストから権限設定を選択します。
- Attendees グループの権限を定義する場合のオプションは、[ブロック] または [許可] です。
- 他のすべてのユーザーおよびグループの権限を定義する場合のオプションは、空白、[ブロック]、または [許可] です。空白を選択すると、ユーザーまたはグループは Attendees グループに対して定義された権限を継承します。
- フル制御権限は強力であり、これを [許可] に設定すると、ユーザーまたはユーザーのグループに管理者権限が付与されます。これによる影響は次のとおりです。
- 管理者に対するすべての権限は [許可] に設定されています。
- 管理者は セッションの名前を変更できます。
- 管理者はセッションを削除できます。
- 管理者は 参加者のアクセス権 を管理できます。
- 管理者は、他のユーザーの権限を管理できます。
- 管理者は、フォルダーのデフォルト権限に関係なく、どのフォルダーに対してもフル権限を持ちます。
ただし、管理者が実行できる操作にはいくつかの制限があります:
- 管理者はホストをブロックできません。
- 管理者は、ホスト(または他の管理者)の グループ にアクセスできません。
- ユーザーまたはグループを削除するには、それらを選択して
を選択します。 - [OK] を選択します。
権限を設定する際には、留意すべき2つの階層セット(権限セットと権限状態)があります。
- [権限セット] は、ユーザーがどのようにして権限を持つようになったかを説明します。ユーザーに個別に割り当てられましたか(個別権限)?それとも、ユーザーは特定のグループに属しているために権限を取得しましたか(グループ権限)?あるいは、上記の2つの条件のどちらも満たされなかったため、ユーザーはデフォルトで一般的な権限になりましたか(一般権限)?
- 権限ステータスは、ユーザーが特定のタスクの実行を許可されているか(許可)、許可されていないか(ブロック)を示します。個々のユーザーとグループの場合、権限ステータスを個別に選択(明示的)するか、空白のままにすることができます。空白にした場合、デフォルトで「Everyone」グループの対応する権限ステータス(継承)になります。
権限状態は Permission Sets 内で機能し、一般的にはユーザーが競合する権限を持つ 2 つ以上のグループに所属している場合に発生する競合を解決するためにのみ使用されます(詳細は以下の例 4 および 5 を参照してください)。通常、ユーザーを複数のグループに追加しないことが推奨されますが、必要な場合は、ホストと管理者が連携して適切な権限が付与されるようにしてください。
階層
階層は以下の通りです:
権限セット
- 個別の権限 (特定のユーザーに対して設定された権限) が最優先されます。
- グループ権限(つまり、作成したグループに対して設定された権限)は、二次的な重要性を持ちます。
- 一般的な権限(つまり、デフォルトの「Everyone」グループに設定された権限)の優先度は最も低くなります。
権限の状態
- Explicit Blocked (that is, a permission that is specifically set to Blocked) has primary importance.
- 明示的な許可(つまり、明示的に [許可] に設定されている権限)の優先度は低くなります。
- 継承された状態(つまり、デフォルトの Everyone グループから継承された、ブロックまたは許可のいずれかの権限)の重要度は最も低くなります。
例
これらの階層を念頭に置いて、ユーザーの実際の権限がどのように決定されるかを示す例をいくつか挙げます。
- ユーザー Alice has individual permissions set up and the Send Invitations permission is set to Blocked.User Alice also belongs to グループ A and the permissions for Send Invitations for グループ A is set to Allowed.Alice will not be able to send invitations to the プロジェクト.
- 彼女の個別の権限は、グループ A の権限よりも優先されます。
- ユーザー Bob has individual permissions set up and the Send Invitations permission is set to Allowed.ユーザー Bob also belongs to グループ A and the permissions for Send Invitations for グループ A is set to Blocked.Bob will be able to send invitations to the プロジェクト.
- 個人の権限は、グループ A の権限よりも優先されます。
- ユーザー Charlie には個別の権限が設定されており、「招待の送信」権限は [許可] に設定されています。ユーザー
Charlie はグループ A にも所属しており、グループ A の「招待の送信」の権限は<blank> に設定されています。全員グループの「招待の送信」権限は [ブロック] に設定されています。Charlie は プロジェクト への招待を送信 できます 。
- 個人の権限は、グループ A の権限よりも優先されます。
- ユーザー Alice には個別の権限が設定されていませんが、「招待の送信」権限が [許可] に設定されているグループ A に所属している一方で、「招待の送信」権限が [ブロック] に設定されているグループ B にも所属しています。Alice は プロジェクト への招待を送信 できません 。
- グループ B の明示的な「ブロック」権限は、グループ A の明示的な「許可」権限よりも優先されます。
- ユーザー Bob には個別の権限が設定されていませんが、[招待を送信] 権限が[許可] に設定されている グループ A および [招待を送信] 権限が に設定されている グループ B<blank> のメンバーです。Everyone グループの [招待を送信] 権限は [ブロック] に設定されています。Bob は プロジェクトへの招待を送信できるようになります。
- グループ A の明示的な許可権限は、グループ B から継承された拒否権限よりも優先されます。