Permissions can be defined in Studio to grant or deny users to specific
Studio Sessions can be configured to have an expiration date. This date can be set up at the time the Session is created or it can be configured afterward. Once an expiration date is set, it can be changed if necessary.
To set or change an expiration date:
When in a Session, click Settings on the Studio tab. The Session Settings dialog box appears.
Note: Expiration dates must be in the future; Revu will not allow a back-dated expiration date.
Revu will send the Host and attendees email notifications as the Session approaches its expiration date. Notifications are sent out:
Similarly, a notification is sent if the Session's expiration date is changed.
Adding a user to a
Click the Attendees tab. Previously added users will appear in the list.
Click the Permissions tab.
The default group, Attendees, will be shown, as well as any other Groups that have been previously added to this
Select the desired user or group and click OK. By default, when users and Groups are added they inherit the permissions of the Attendees group.
Note: Individual users will not appear in the list until after they have accessed the
If you would like to create a new Group or change the membership of an existing one, click
Note: When creating Groups, keep in mind that Revu will allow somebody to be in multiple Groups within the same Session
Administrators can manage Permissions for other
There are some limits on what administrators can do, however:
When setting permissions, there are two sets of hierarchies to keep in mind: Permission Sets and Permission States.
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.
The hierarchies are:
- Individual permissions (that is, those set up for a specific user) have primary importance.
- Group permissions (that is, those set up for a Group you have created) have secondary importance.
- General permissions (that is, those set up for the default
Attendeesgroup) have the least importance.
- Explicit Deny (that is, a permission that is specifically set to Deny) has primary importance.
- Explicit Allow (that is, a permission that is specifically set to Allow) has secondary importance.
- Inherited State (that is, any permission—whether it is Deny or Allow—that is inherited from the default
Attendeesgroup) has the least importance.
With these hierarchies in mind, here are a couple examples that should help illustrate how a user's actual permissions are determined:
Defining Access and Permissions in Studio Projects
Host a Studio Session
The Studio Tab