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.
Click the Desktop tab.
In the toolbar on the left, click New and then select Role from the drop down menu.
In the Create new Role screen, enter a Name and Description.
Click Save to finalise.
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.
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.
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:
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:
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 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.
Once you have configured the permissions for a role, you can assign the role a user.
Navigate to the Details section for your selected user and click Edit.
Click the Role drop down menu.
Select your desired role from the list to apply it to the user.
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:
The User Administrator cannot for example:
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:
The Producer cannot for example:
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:
The Editor cannot for example:
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:
The viewer cannot for example: