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. Note that you can only apply one role per user.
The permissions in this section are divided into areas of the Ooyala Flex console.
The permissions that are assigned have a selected check box next to them:
A selected checkbox next to a permission shows that the permission has been assigned.
An Overview of the Permissions Sections
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 is also displayed, containing permission check boxes, for any custom objects that you have created. 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.
An Overview of each Section
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.
- Act As: Allows a user to act as another. See <xref href="users_switching_between_users.html">Switching Between Users</xref> for more information.
- Delete Locks, Job Lock Releasing:See the Locking section of the <xref href="general_configuration.html">object configuration page</xref> for more information.
- Destroy: Allows a user to delete all configured details, and return the system to its starting state.
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.
Note: Each new custom object type you create is displayed in this section in a row of its own. For example: if you created a custom object type called Version, it would appear in the list in alphabetical order.
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
To apply a role to a new or existing user, navigate to the details section for that user, and click the Role drop down. Then you just need to select the role you have created from the list.