Commands

The complete list of commands is as follows:

Essential Commands

Below is a detailed list of the most important commands that Configuration Manager supports along with use case examples. With most of the following commands, you will be able to select all the available objects, by simply executing a command by itself.

For example: If you were to execute the pull command by itself, without specifying a particular object type, you would pull all of the available object types.

showrepos

The showrepos command displays the repositories you’ve created.

Example: Available repositories: - Repository name: my_repo

status

The status command displays the status of the Change Request created by the system. If you use the status command, you will see a response which is similar to the following:

open --source <name_of_source_env> --target <name_of_target_env>

This command creates a new change request. With this command, you can change which environment is your source and which is the target for a particular change session.

Example: open --source my_source_env --target my_target_env

If the change session has been setup successfully, you will see the following response:

Note: The name of source and target environment should match the folder name in your repository.

open --cr change_request_name

This command is used to switch the environments or load an existing change request.

Example: "ChangeRequest loaded: [name=CR_0612151434, uuid=66d36f8f-7f9a-4dd0-b5f6-d3f9887657ba, source=DEV, target=QA, created on=12/06/2015 14:34:09, committed on= not yet]"

open --source <name_of_env> --target <name_of_env> --keep_organisational

By running this command, you can indicate whether or not to keep account / user settings that are found in the source environment, and apply them to the target environment. So when you pull items, and then push them to the target, they will automatically conform to the organisational details you have specified.

The following options can be used with this command:

• all: By specifying this option, you can keep all the account / user settings found in the source, and apply them to the target.
• none: By specifying this option, you are choosing not to apply any of the account / user settings found in the source environment, to the target environment.
• user: By specify this option, you are only choosing to apply the user settings found in your source environment, to your target environment.
• account: By specify this option, you are only choosing to apply the account settings found in your source environment, to your target environment.

Example: The following command would keep all the settings associated with users.

open --<source_env_name> --<target_env_name> --keep_organisational user

session

The session command provides you with the details of the current session.

Example: Working path: C:\miocm_reposRepository: MioCMEnvironments: There are 2 environments  - Environment name: MioStage  - Environment name: MioStageTargetCurrent CR: There is no change request open

list

list [[--type <object_type>]|[--uuid <uuid>]][--environment source|target]]|<none>

The list command currently supports the following object types:

• Action
• Account
• Workflow Definition
• Resource
• Metadata Definition
• Event Handler
• Message Template
• Profile
• Player Definition
• Timed Action
• Account Property
• Group
• Workspace
• User
• Role
• User Defined Object Type

Example: Using List --type action lets you see a list of all the actions you have in a particular environment. The information for each action in the list will be displayed in the following order <lastmodified><uuid><type_object><name>. This is shown in the screenshot below:

pull

The pull command lets you pull objects from an environment.

pull [[--type <object_type>]|[--uuid <uuid>]] [--environment source|target]] | <none>

Examples:

• pull --environment source | target
• pull --type --action
• pull --uuid --<uuid>

By default, executing the pull command will pull objects from the source environment. If you execute the pull command by itself without specifying an object type, Configuration Manager will pull all the available object types by default.

If you use the pull --environment command, you can select --environment 'source|target' label.

The pull --type action command will take all the actions from the source environment, and send them to the source folder inside the repository.

The pull command currently supports the following object types:

• Action
• Account
• Workflow Definition
• Resource
• Metadata Definition
• Event Handler
• Message Template
• Profile
• Player Definition
• Timed Action
• Account Property
• Group
• Workspace
• User
• Role
• User Defined Object Type

add

add [[--type <object_type>]|[--uuid <uuid>]]|<none>

The add command is used to push changes to the target folder. If the object type and UUID are not specified, all of the environment configuration will be copied across to the target by default. So it is important to specify the object type and UUID if you are only changing one object for example. If you execute the add command by itself without specifying an object type, Configuration Manager will add all the available object types by default.

Examples:

• add --type action
• add --uuid <uuid>

The add command currently supports the following object types:

• Action
• Account
• Workflow Definition
• Resource
• Metadata Definition
• Event Handler
• Message Template
• Profile
• Player Definition
• Timed Action
• Account Property
• Group
• Workspace
• User
• Role
• User Defined Object Type

update

update [[--type <object_type>]|[--uuid <uuid>]]|<none>

The Update command is used to update the target folder with the delta records. If you execute the update command by itself without specifying an object type, Configuration Manager will update all the available object types by default.

The update command currently supports the following object types:

• Action
• Account
• Workflow Definition
• Resource
• Metadata Definition
• Event Handler
• Message Template
• Profile
• Player Definition
• Timed Action
• Account Property
• Group
• Workspace
• User
• Role
• User Defined Object Type

commit

The commit command is used to commit changes you have made, to the git repository.

commit [[--type <object_type>]|[--uuid <uuid>]][--message <message_text>][--force true|false][--skip_git_status true|false]

Examples:

• commit --message "This is a message providing details about this particular commit"

With this command, you can add messages to your commit so that you can differentiate between different commits in the git repository. If you have spaces in your message you must wrap the message in quotes.

• commit --type action
• commit --uuid <uuid>

Additionally, the commit command accepts the --force option. This option will change all of the conflict questions to "Include all" without confirmation from the User. If you choose to use the --force option, all questions will be changed to "Include all" by default. The --force param will be passed from Ooyala FlexCM CLI to Ooyala Flex Core. In Case 4, Ooyala Flex Core will try to perform the change and return a warning message (meaning it will inform you of the conflicts but will attempt to commit the changes anyway).

remove

[[--type <object_type>]|[--uuid <uuid>]]|<none>

The remove --type command currently supports the following object types:

• Action
• Account
• Workflow Definition
• Resource
• Metadata Definition
• Event Handler
• Message Template
• Profile
• Player Definition
• Timed Action
• Account Property
• Group
• Workspace
• User
• Role
• User Defined Object Type

dependencies

The dependencies command lists the dependencies of a specific object. This is done by passing the UUID for the object located in the remote environment. For example: you could have a workflow, and that workflow might reference several other objects in order to work, such as actions, event handlers, and so forth. The objects that are referenced by the workflow, may in turn, reference objects as well.

Note: You must open a change session first, in order to use this command.

Below is an example of a list of dependencies for a specific object:

dependencies --environment target --uuid 2bd43348-d6e0-475d-bbd0-be0699a91fef { "dependencies" : [ { "referenceLink" : { "id" : 19362, "uuid" : "2bd43348-d6e0-475d-bbd0-be0699a91fef", "name" : "!Achal Add to Group Action", "displayName" : "!Achal Add to Group Action", "externalIds" : [ ], "objectType" : { "id" : 18, "name" : "action", "href" : "https://my.environment.net/api/objectTypes/18", "displayName" : "Action", "pluralName" : "Actions", "userDefined" : false, "attachmentsSupported" : true, "commentsSupported" : true, "objectDataSupported" : false, "contentMetadataSupported" : false, "metadataSupported" : true }, "accountId" : 18487, "enabled" : true }, "upstream" : [ ], "downstream" : [ ] } ] }

mapper

The mapper command allows you to map a user, account, or visibility from one environment and apply it to an object located in another environment using UUIDs.

Note: The mapper command doesn’t map internal configuration references. For example, an action using a metadata definition in the configuration will not have the UUID mapped. Only access details are mapped: such as user, account, and visibility.

You need to specify the UUID of the object type you wish to map, and then the UUID of the object you want to map it to.

In order to use this command, you must first specify the object UUIDs in a JSON file. For example you could have the following:

"mapping": [ { "sourceUuid": "4508649d-d697-4c75-8fa0-27ac4ca674c4", "targetUuid": "786a8a14-6533-41c9-ad22-8a54fe9bcbd9" },... ]

Once you specified the UUIDs in the JSON file, you need to run the following command, containing the exact path to where your JSON file is located.

Example

mapper --file D:/mappers/owner_account_mapping.json