Roles and Permissions

Creating roles gives you the ability to control what users can see and do in Ooyala Flex.

You can create roles based on the jobs that exist within your organisation. For example, if you have an Editor in your organisation, you might create a role that has permissions specific to that position.

Creating a Role

  1. Click the Desktop tab.

  2. In the toolbar on the left, click New and then select Role from the drop down menu.

  3. In the Create new Role screen, enter a Name and Description.

  4. Click Save to finalise.

Permissions

Once you have created a role, you can apply permissions to that role. The number and type of permissions are dependent on your role. The person who has created your account usually assigns you a role, and then sets the permissions for it. This might mean that you have access to certain areas of your organisation’s Ooyala Flex account, and not others.

The permissions in this section are divided into areas of the Ooyala Flex Console.

Assigning Permissions

When you create a new role, you must then assign permissions to that role. To do this, open the Permissions tab in the Role Details screen. The permissions are divided up into the following sections: Functionality, Objects, and User Interface.

Within each of these sections, several rows are displayed. These rows represent different categories relating to each section. For example, in the Objects section, a row is displayed for each object type, such as account workspaces, accounts, actions, event handlers, and so on.

A row containing permission checkboxes for any custom objects that you have created is also displayed. In the example below, a row is displayed providing permissions options for a custom object type called Episode.

Select individual check boxes in each row to select the specific permissions for a role.

Alternatively, if you want to assign all the permissions in a particular row, click the All check box located to the right of the row.

Sections Overview

Functionality

In the Functionality section only one row, the Function row, is displayed. Functionality permissions control access to global Ooyala Flex Console functionality, such as workspaces and search, thus allowing you to control what functions can be carried out by a specific role. You might assign some, if not all these permissions to an advanced role such as a Systems Administrator, so that they have full control over functionality in Ooyala Flex.

The following list gives some more details about some of these functions:

  • Act As: Allows a user to act as another. See Acting as another User for more information.
  • Delete Locks, Job Lock Releasing: See the Locking section of the General Configuration for more information.
  • Destroy: Allows a user to delete all configured details, and return the system to its starting state.

Objects

Object permissions control the level of access to the object types that exist in Ooyala Flex. Examples of object types are tasks, workflow instances, and assets. The following list describes the access level that can be applied to each type:

  • List: Allows a user to search for and see a list of these object types
  • Create: Allows a user to create an object of this type
  • View: Allows a user to view details of an object of this type
  • Edit: Allows a user to edit an object of this type
  • Enable: Allows a user to enable an object of this type (not all types can be enabled)
  • Disable: Allows a user to disable an object of this type (not all types can be disabled)
  • Start: Allows a user to start an object of this type (not all types can be started)
  • Stop: Allows a user to stop an object of this type (not all types can be stopped)
  • Delete: Allows a user to delete an object of this type (not all types can be deleted)
  • Reference: Allows a user to reference an object of this type (the object must be visible to this account first) without being able to view (or edit) the details of this object
  • Approve: Allows a user to approve and un-approve an object of this type (not all types can be approved)

The following are examples of rows in the Objects section:

  • Master Account: The master account is immutable and always exists. This account is created when a new Ooyala Flex platform is installed. The master account owns all other accounts, and is only accessed by the master user. A master account is primarily used for setting up other accounts as well as system-wide configuration. The only permission that can be altered for a master account is the ability to reference it.

  • Master Role: The master role is included with the master account, and is created automatically upon installation of Ooyala Flex. The master role has all permissions assigned and cannot be changed. Therefore the only permission that can be changed in regards to the master role is the ability to reference it.

  • Message Templates: Message templates are used to specify and format messages to be sent to users when various events occur: for example, when a new user is created, you can send them a message that prompts them to change their password.

  • Roles: Here you can specify permissions relating to other roles in Ooyala Flex. You can decide whether the role you are creating can search for and see lists of other roles, as well as create, view, edit, delete, reference, and rename other roles in Ooyala Flex. For example, you might create an administrator role with all permissions.

  • Sub-Accounts: Here you can specify permissions relating to sub-accounts. A sub-account represents an account that belongs to an existing account. Sub-accounts are useful, for example when an account that belongs to a single company must be split up into multiple business units with self-administration.

  • Users: Here you can specify permissions relating to users. You can decide whether a role can search for and see lists of users, as well as create, view, edit, enable, disable, delete, reference, and rename users. For example, you might assign all permissions to an administrator role.

User Interface

User Interface Permissions control access to elements of the Ooyala Flex Console. By using these permissions, you can display only the relevant UI elements to a user so that the interface is clearer. There may be some User Interface elements that you want a user to see, and some you may not want them to see depending on their responsibilities as well as where they are positioned in the organisational hierarchy.

The permissions in this section are divided into areas of the Ooyala Flex Console. It is unlikely that any role can see all elements of the Ooyala Flex Console.

Applying a Role to a User or a Group

Once you have configured the permissions for a role, you can assign the role to a user or to a group.

To apply a role to a new or existing user (or group)

  1. Navigate to the Details section for your selected user (or group) and click Edit.

  2. Click the Role drop down menu.

  3. Select your desired role from the list to apply it to the user (or group). Image

  4. Click Save.

Example Roles

User Administrator

An Administrator doesn’t necessarily mean that the role is technical in nature. In some organisations there are different types of administrators depending on the industry, such as a User Administrator and a System Administrator. In this case we will use the example of a User Administrator. The User Administrator will only be able to work with things in Ooyala Flex that can be owned such as objects. They will not, on the other hand, have access to anything that will make changes to the system. Anything system related will be left in the hands of a System Administrator who will have the correct permissions.

The User Administrator can for example:

  • Upload, manage, publish, and delete files
  • Create and delete users
  • Add and remove users from groups
  • Create and delete user groups

The User Administrator cannot for example:

  • Make changes to workflows
  • Make changes to metadata schema
  • Create or edit roles
  • Add or remove permissions from roles (including their own role)

Producer

In many different industries a Producer is somebody who produces content, but hands over the responsibility of editing the content to somebody else, such as an Editor. In this example the Producer purely produces the content.

The Producer can for example:

  • Create content to be uploaded
  • Upload content that they have created
  • Delete content that they have created
  • View content that they have uploaded

The Producer cannot for example:

  • Edit the content they have uploaded

Editor

An Editor is someone who will have the permissions to make use of the content that has been uploaded, but will not be able to create or delete content. They will only be able to work with pre-existing content. A Producer will probably upload the content they have produced, and the Editor will begin editing it.

The Editor can for example:

  • View pre-existing content
  • Edit pre-existing content

The Editor cannot for example:

  • Upload content to Ooyala Flex
  • Delete Content from Ooyala Flex

Viewer

A Viewer is an example of someone who has very limited permissions. They will only be able to search for and view content that has been uploaded and edited.

The viewer can for example:

  • Search for content that has been uploaded
  • View content in lists and search results
  • Play content such as Media Assets

The viewer cannot for example:

  • Upload content to Ooyala Flex
  • Make changes to pre-existing content
  • Delete content