Permissions

Once you have created a role, you can apply permissions to that role. The type of permissions as well as how many you have is dependent on your role. The person who has created your account will usually assign you a role, and then set the permissions for it. This might mean that you have access to certain areas of your organisation's Ooyala Flex account, and not others. It is important to 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 ticked check box next to them.

An overview of the Permissions sections

When you create a new role, you must then assign permissions to that role. To do this you must go to 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 you will see several rows. These rows represent different categories relating to each section. For example: in the Objects section you will see a row for each object type, such as account workspaces, accounts, actions, event handlers, and so on.

You will also see a row containing permission check boxes for any custom objects that you have created. In the example below, you can see a row providing permissions options for a custom object type called Episode.

You can select the specific permissions for a role by selecting individual check boxes in each row.

Alterely, if you wanted to assign all the permissions in a particular row, you could simply click the All check box located to the right of the row.

An overview of each section

Functionality

In the Functionality section you will only see one row, the Function row. 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. These permissions include the ability to act as another user using the global search, being able to switch between different accounts, manage workspaces, and so on. 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.

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 access level that can be applied to each object type are described below:

List: Allows users 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 has to 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 rows that are present in the Objects section are as follows:

Account Workspaces: Here you can control whether or not a role is able to reference a workspace.

Accounts: Here you can specify permissions relating to accounts. You can decide whether or not a role can search for and see lists of accounts, as well as view, edit, enable, disable, delete, rename, or reference accounts. You would most likely select permissions based on the nature of the role. For example: you may want a certain roles to be able to view accounts, but not be able to delete or edit them.

Actions: Here you can specify permissions relating to actions. You can decide whether or not a role can view, search for, and see lists of actions, as well as create, view, edit, enable, disable, delete, rename, or reference an actions. For example: you might want certain roles to be able to view actions, but not be able to disable or rename them.

Event Handlers: Here you can specify permissions relating to event handlers. You can decide whether or not a role can search for and see lists of event handlers, as well as create, edit, enable, disable, start stop, and reference event handlers. For example: you might want a role to be able to stop and start an event handler, but not be able to delete or disable it.

Group Assets: Here you can specify permissions relating to group assets. You can decide whether or not a role can search for and see lists of group assets, as well as create, view, edit, delete, reference, approve, and rename group assets. For example: you might want a role to be able to create a group asset, but not be able to approve it.

Groups: Here you can specify permissions relating to groups. You can decide whether or not a role can search for and see lists of groups, as well as create, view, edit, enable, disable, delete, reference, and rename groups. For example: you might want a role to be able to view groups, but not be able to create, edit, delete or rename them.

Image Assets: Here you can specify permissions relating to image assets. You can decide whether or not a role can search for and see lists of image assets, as well as create, view, edit, delete, reference, approve, and rename image assets. For example: you might want a role to able to view image assets but not be able to edit, create, or delete them.

Jobs: Here you can specify permissions relating to jobs. You can decide whether or not a role can search for and see lists of jobs, as well as create, view, edit, reference, and delete jobs. For example: you might want a role to able to create a Job but not be able to delete it.

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.

Media Assets: Here you can specify permissions relating to media assets. You can decide whether or not a role can search for and see lists of media assets, as well as create, view, edit, delete, reference, approve, and rename media assets. For example, depending on their position in the organisation's hierarchy, you might want a role to simply reference and view assets, but not create, edit, or delete them.

Message Templates: Message templates are used to specify and format messages that are to be sent to users when various events occur, for example: when a new user is created, you can send them a message which prompts them change their password. You can decide whether or not a role can search for and see lists of message templates, as well as create, view, edit, enable, disable, delete, reference, and rename message templates. For example: you might want a role to only be able to view a message template, but not be able to edit, delete, disable, rename it and so on.

Metadata Definitions: Here you can specify permissions relating to metadata definitions. You can decide whether or not a role can search for and see lists of metadata definitions, as well as create, view, edit, enable, disable, delete, reference, and rename metadata definitions. For example: you might want a specific role to be able to create and edit metadata definitions, but not be able to enable or disable them because they must be passed onto someone else in the organisation in order to be enabled or disabled.

Object Types: Here you can specify permissions relating to object types. You can decide whether or not a role can search for and see lists of object types, as well as create, view, edit, enable, disable, delete, reference, and rename an object type. For example: you may only want certain roles to be able to view object types, so you would only select the View check box.

Player Definitions: Here you can specify permissions relating to player definitions. You can decide whether or not a role can search for and see lists of player definitions, as well as create, view, edit, enable disable, delete, reference, and rename player definitions. For example: depending on a users' seniority within the company, you may only want them to be able to view player definitions. So in that case you would only select the View checkbox. If someone was more senior in the organisational structure, you may want to grant them the permission to create, enable, disable them and so on.

Players: Here you can specify permissions relating to players. You can decide whether or not a role can search for and see lists of players, as well as create, view, edit, delete, and reference players.

Profiles: Here you can specify permissions relating to players. You can decide whether or not a role can search for and see lists of profiles, as well as create, view, edit, delete, and reference profiles.

Quotas: Here you can specify permissions relating to quotas. You can decide whether or not a role can search for and see lists of quotas, as well as create, view, edit, enable, disable, delete, reference, and rename quotas.

Report Definitions: Here you can specify permissions relating to report definitions. You can decide whether or not a role can search for and see lists of report definitions, as well as create, view, edit, enable, disable, delete, reference, and rename report definitions.

Resources: Here you can specify permissions relating to resources. You can decide whether or not a role can search for and see lists of resources, as well as create, view, edit, enable, disable, start, stop, delete, reference, and rename resources.

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 which has all of these 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 needs to be split up into multiple business units with self-administration. You can decide whether a role can search for and see lists of sub-accounts, as well as create, view, edit, enable, disable, delete, reference, and rename sub-accounts.

Task Definitions: Here you can specify permissions relating to task definitions. You can decide whether a role can search for and see lists of task definitions, as well as create, view, edit, enable, disable, delete, reference, and rename task definitions.

Tasks: Here you can specify permissions relating to tasks. You can decide whether a role can search for and see lists of tasks, as well as create, view, edit, and reference tasks.

Timed Actions: Here you can specify permissions relating to timed actions. You can decide whether or not a role can search for and see lists of timed actions, as well as create, view, edit, start, stop, delete, reference, and rename timed actions.

Users: Here you can specify permissions relating to users. You can decide whether or not 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 of these permissions to an administrator role.

Wizards: Here you can specify permissions relating to wizards. You can decide whether or not a role can search for and see lists of wizards, as well as create, view, edit, enable, disable, delete, reference, and rename wizards.

Workflow Definitions: Here you can specify permissions relating to workflow definitions. You can decide whether or not a tole can search for and see lists of workflow definitions, as well as create, view, edit, delete, reference, and rename workflow definitions.

• Workflows: Here you can specify permissions relating to workflows. You can decide whether or not a role can search for and see lists of workflows, as well as create, view, edit, reference, and delete workflows.

Workspaces: Here you can specify permissions relating to workspaces You can decide whether or not a role can search for and see lists of workspaces, as well as create, view, edit, delete, reference, enable, disable, and rename workspaces.

Note: Each new custom object type you create will appear 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

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 will be able to see all elements of the Ooyala Flex Console.

Access Section: Here you can specify permissions relating certain user interface elements found in the Access tab in the Ooyala Flex console. The Only feature found in the Access tab is the search feature. You can either give a permission to access the search functionality, or not access it at all.

Admin Section: Here you can specify whether or not a role has access to some the administrative features of Ooyala Flex . These are: dead letter queue logs, Ooyala Flex Playout tokens, re-index, system configuration, and upload custom files.

Assets Section: Here you can specify whether or not a role has access to certain user interface elements found in the Assets tab. You can decide whether or not a role has access to the asset search feature, and the Trash bin.

Desktop Section: Here you can specify whether or not a role has access to certain user interface elements found in the Desktop tab. These include access to events, the system summary, the Web Uploader. Dependant on where the user is in the organisational hierarchy, you might want to either give or deny the permissions for the Web Uploader. For example: you might not want certain users to be able to upload assets to Ooyala Flex.

Jobs Section: Here you can specify whether or not a role has access to certain user interface elements found in the Jobs tab. This includes access to any failed jobs, and the jobs search feature.

Players Section: Here you can specify whether or not a role has access to the search feature found in the Players tab.

Resources Section: Here you can specify whether or not a role has the ability to manage resources. This feature is found in the Resources tab.

• Settings Section: Here you can specify whether or not a role has access to certain user interface elements found in the Settings tab. This includes the settings search feature, the ability to change the theme of the Ooyala Flex console, and variants.

Tasks Section: Here you can specify whether or not a role has access to certain user interface elements found in the Tasks tab. This includes the My Tasks section, and the tasks search feature.

Workflows Section: Here you can specify whether or not a role has access to certain user interface elements found in the Workflows tab. This includes the ability to access a list of failed workflows, and the workflows search feature.

Applying a Role to a User

To apply a role to a new or existing user, simply 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.

Was this article helpful?