Adding a user to a Project can have different effects depending on whether or not the Project is set to restrict access. When Restrict Users is enabled, adding a user is the only way to grant them access. Conversely, when Restrict Users is not enabled, adding a user is the only way to deny them access. Restricted user access is discussed in more detail below.

Adding a user to a Project does not send them an invitation to join the Project. For that, see Start a Studio Project: Inviting Users to the Project.

To add a User to the Project:

1. When in the Project, click Settings on the Studio tab. The Project Settings dialog box appears.

2. Click the User Access tab. Previously added users will appear in the list.

   

3. To add new, individual users, click. The Add E-mail Address dialog box opens.  Enter the user's email address and click OK.
4. To add the users in a Group, click. TheSelect Groups dialog box opens. Select the desired group and click OK. All the users in that Group are automatically added.
5. By default, all users added to the User Access tab automatically have their Access set to Allow. To deny access to a specific user (for example, one brought in with a Group that should not have access to this specific Project), select the desired user and click Deny.
6. To restrict access to this Project to only those users listed on the User Access tab whose Access is set to Allow, select Restrict Users.
   • The relationship between this setting and a user's Access status (either Allow or Deny) lets you set up the equivalent of a "white list" or a "black list" and merits some further explanation:
     • When Restrict Users is checked, only users listed here on the User Access tab whose Access is set to Allow will be able to access this Project. This is the equivalent of a "white list."
     • When Restrict Users is not checked, any user can access the Project except for those listed here on the User Access tab whose Access is set to Deny. This is the equivalent of a "black list."
7. Click OK.
   

1. When in the Project, click Settings on the Studio tab. The Project Settings dialog box appears.

2. Click the Permissions tab.

   

   The default group, Everyone, will be shown, as well as any other Groups that have been previously added to this Project. The Everyone group applies to all users in the Project and its initial permission settings are configured when the Project is created. It cannot be deleted. Most permissions for the Everyone group are set to Deny when the Project is created; a recommended best practice is to give additional permissions to specific users and Groups rather than allow greater access to the Everyone group.
   

3. To add individual users or Groups:
   1. Click. The Add Users/Groups dialog box opens.

   2. Select the desired user or group and click OK. By default, when users and Groups are added they inherit the permissions of the Everyone group.

      Note: Individual users will not appear in the list until after they have accessed the Project for the first time.

      • If you would like to create a new Group or change the membership of an existing one, click Manage Groups. See Studio Groups for more information about creating and managing groups.This function is only available to the Host.

        Note: When creating Groups, keep in mind that Revu will allow somebody to be in multiple Groups within the same Session or Project; when this occurs, that person's permissions will default to whichever is the most restrictive. As such, adding somebody who is already in a Group to a second Group might not have the desired effect, either by not granting expected permissions (because the first Group's are more restrictive), or by imposing undesired restrictions (because the second Group's are more restrictive). Coordination when creating Groups is highly recommended.

4. To change the permissions for a user or Group:
   1. Select the desired user or Group in the Users/Groups list.
   2. Select the desired permission in the Applied Permissions list. A dropdown list arrow will appear to the right of the selected permission.
   3. Select a permission setting from the dropdown list.
      • When defining permissions for the group, the options are Deny or Allow.
      • When defining permission for all other users and Groups, then options are blank, Deny or Allow. Selecting blank will cause the user or Group to inherit the permission defined for the group.
      • The Full Control permission is powerful and setting it to Allow gives the user or Group of users administrator powers. The effects of this are:
        • All permissions for administrators are set to Allow.
        • Administrators can rename the Project.
        • Administrators can delete the Project.
        • Administrators can manage User Access.

        • Administrators can manage Permissions for other users.

        • Administrators have full permissions to any folder, regardless of the folder's default permissions.

        There are some limits on what administrators can do, however:

        • Administrators cannot block the Host.
        • Administrators do not have access to the Host's (or any other administrator's) Groups.
5. To remove a user or Group, select them and click .
6. Click OK.

Folder permissions control user access to folders and the files within those folders. They do not apply to Hosts and administrators (that is, users with the Full Control permission set to Allow), who automatically have full access to all files and folders in the Project.

1. When in a Project, click Settings on the Studio tab. The Project Settings dialog box appears.

2. Click the Folder Permissions tab.

   

   The default group, Everyone, will be shown, as well as any other Groups that have been previously added to this Project. The Everyone group applies to all users in the Project and cannot be deleted. By default, the Everyone group is set to Read when the Project is created; a recommended best practice is to give additional permissions to specific users and Groups rather than allow greater access to the Everyone group.

3. To add individual users or Groups:
   1. Click. The Add Users/Groups dialog box opens.

   2. Select the desired user or group and click OK. By default, when users and Groups are added, they inherit the permissions of the Everyone group.

      Note: Individual users will not appear in the list until after they have accessed the Project for the first time.

      • If you would like to create a new Group or change the membership of an existing one, click Manage Groups. See Studio Groups for more information about creating and managing groups.This function is only available to the Host or administrators (that is, users with Full Control permissions on the Permissions tab, as described in Setting Permissions in a Studio Project above).
4. To change the folder permissions for a user or Group:
   1. Select the desired user or Group in the Users/Groups list.
   2. Select the desired folder in the Applied Permissions list. A dropdown list arrow will appear to the right of the selected folder.
      • All Projects have a folder designated the Project Root. This root-level folder contains all folders and files in the Project, even though it does not show up in the list of Project files and folders on the Studio tab. The Project Root folder must have a permission state defined for it, but it is the only one; all other folders can be set to inherit their permission states from their parent folders.
   3. Select a permission setting from the dropdown list.
      • When defining folder permissions for the Project Root folder, the options are Read, Read/Write or Read/Write/Delete.
      • When defining permission for all other users and Groups, the options are:
        • blank: This setting causes the folder to inherit the permission state defined for its parent folder (that is, the one in which it is contained). Not available for the Project Root folder as it has no parent folder from which to inherit a permission state.
        • Hidden: This setting causes the folder and its contents to be concealed from the user or Group. They will not see or be able to access the folder or any of the files contained therein. The Project Root folder cannot be hidden. Further, any folders contained within a Hidden folder are also Hidden by default.
        • Read: This setting allows the user to open Project files, but not check out, change or delete them.
        • Read/Write: This setting allows the user to open, check out and make changes to Project files.
        • Read/Write/Delete: This setting allows the user to open, check out, make changes to and delete Project files.

      Note: Folder permissions do not apply to the Host or administrators (that is, users with the Full Control permission set to Allow). These users automatically have full access to all files and folders in the Project.

5. To remove a user or Group, select them and click .
6. Click OK.

When setting permissions, there are two sets of hierarchies to keep in mind: Permission Sets and Permission States.

• A Permission Set describes how a user came to have their permissions: Were they assigned to the user specifically (Individual permissions)? Did the user pick them up by virtue of belonging to a certain Group (Group permissions)? Or did the user default to the general permissions because neither of the previous two conditions were met (General permissions)?
• A Permission State describes whether the user is permitted to perform a certain task (Allow) or not (Deny). For individual users and Groups, permission states can either be specifically selected (Explicit) or they can be left blank , causing them to default to whatever the corresponding permission state is for the Everyone group (Inherited).

Permission States work within Permission Sets and generally come into play only to resolve conflicts that arise when a user is a member of two or more Groups that have conflicting permissions (see examples 4 and 5 below for further illustration). It is generally recommended that people not be added to multiple Groups, but in the event that it is necessary, Hosts and administrators should coordinate to ensure that the proper permissions are granted.

Hierarchies

The hierarchies are:

Permission Sets

1. Individual permissions (that is, those set up for a specific user) have primary importance.
2. Group permissions (that is, those set up for a Group you have created) have secondary importance.
3. General permissions (that is, those set up for the default Everyone group) have the least importance.

Permission States

1. Explicit Deny (that is, a permission that is specifically set to Deny) has primary importance.
2. Explicit Allow (that is, a permission that is specifically set to Allow) has secondary importance.
3. Inherited State (that is, any permission—whether it is Deny or Allow—that is inherited from the default Everyone group) has the least importance.

Examples

With these hierarchies in mind, here are a couple examples that should help illustrate how a user's actual permissions are determined:

1. User Alice has individual permissions set up and the Send Invitations permission is set to Deny. User Alice also belongs to Group A and the permissions for Send Invitations for Group A is set to Allow. Alice will not be able to send invitations to the Project.
   • Her individual permissions overrule the Group A permissions.
2. User Bob has individual permissions set up and the Send Invitations permission is set to Allow. User Bob also belongs to Group A and the permissions for Send Invitations for Group A is set to Deny. Bob will be able to send invitations to the Project.
   • His individual permissions overrule the Group A permissions.
3. User Charlie has individual permissions set up and the Send Invitations permission is set to Allow. User Charlie also belongs to Group A and the permissions for Send Invitations for Group A is set to <blank>. The Send Invitations permission for the Everyone group is set to Deny. Charlie will be able to send invitations to the Project.
   • His individual permissions overrule the Group A permissions.
4. User Alice does not have individual permissions set up, but she is part of Group A that has the Send Invitations permission set to Allow and she is also part of Group B that has the Send Invitations permission set to Deny. Alice will not be able to send invitations to the Project.
   • The explicit Deny permission from Group B overrules the explicit Allow permission from Group A.
5. User Bob does not have individual permissions set up, but he is part of Group A that has the Send Invitations permission set to Allow and he is part of Group B that has the Send Invitations permission set to <blank>. The Send Invitations permission for the Everyone group is set to Deny. Bob will be able to send invitations to the Project.
   • The explicit Allow permission from Group A overrules the inherited Deny permission from Group B.