LiveGroup Asset Functions

A studio may decide to use permissions for working with certain assets on a project. These permissions may depend on the name of the current user, the name of the user’s workstation, or certain environment variables for a project, such as show, shot, or sequence. Katana’s AssetAPI supports such access permissions through a dedicated function, checkPermissions(), which is called for certain LiveGroup operations. When a function to check permissions in a specific context is called, the asset API plug-in queries the Asset Management System (AMS) to check general permissions or permissions for working with the asset with the given ID in the given context. Checking permissions for a given ID can be used to check whether the current user has sufficient permissions to edit the asset or whether the asset has already been checked out for editing.

Note:  It is possible, with a custom implementation leveraging the Asset Management System, to inform users of editable permission errors, such as when another user is currently editing the LiveGroup source of the node you’re attempting to edit. If another LiveGroup node references the same LiveGroup source and has been made editable by another user, an error is displayed and the state of the node is not changed.

The function signature for checking permissions is:

checkPermissions(assetID: string, context: map of string to string): bool

The context dictionary contains information about the context from which to check permissions, with names of information fields as keys and values of information fields as values. For example, the following might be produced:

• action = edit

• shot = ts520

• show = srow

• username = name

• workstation = seat

When the function to run a custom asset plug-in command is called the asset API plug-in uses the AMS to check if the command succeeds or fails. The function signature to run the plug-in command is:

runAssetPluginCommand(assetID: string, command: string, commandArgs: map of string): bool

The command parameter receives the command to execute, for example:

• acquireLock

• releaseLock

The commandArgs dictionary contains information about the arguments with which to customize the execution of the given command, with names of command arguments as keys and values of command arguments as values. The commandArgs dictionary may be empty.