Configuration settings for Tentaculo consist in creating a configuration file in the json-format and then uploading it to Cerebro.
Uploading configuration
In order to upload a configuration file to Cerebro:
open Administrator window (Main menu - Tools - Administrator...);
go to Universe tab;
go to Tentaculo section;
in this section, click on Load the configuration setting from the file....
After the upload is completed, Tentaculo configuration will be available to all users in your universe.
Note:
In order to make sure that the configuration is correct, it is recommended to use the debug mode first.
Configuration setting
Configuring the Tentaculo configuration consists of the following parts:
configuring the file storage access protocol. To do this, you need to fill in two sections in the configuration file:
- protocol – list of storage access protocols;
- project_path – list of projects' root paths.configuring the naming convention. To do this, you need to fill:
file_path – a task description list in Cerebro which match your file structure;
soft_folder – is an additional variable for structuring files and directories – depending on the local application in which the files are created. It is used in file_path to describe file paths;
version_save — the variable defines what happens to the work file when saving the version;
trans_mode – this variable allows you to enable transliteration of file paths corresponding to tasks for each application in Cerebro;
case_mode – this variable allows you to define the character case in file paths;
filters — the variable allows you to set task filtering parameters in the Tentaculo interface;
mirada_path– this variable allows you to set the full path to the Mirada application.
expansion expanding Tentaculo features:
- processors – defines a set of Python scripts that are additionally executed when performing actions in the plugin (see the Processors section);
Access protocol setting
Section protocol
The protocol variable allows you to configure file access protocols; note that different values are possible depending on the application in which the plugin is launched.
Element structure:
"protocol":
{
"all": [],
"cerebro": [],
"maya": [],
"nuke": [],
"houdini": [],
"blender": [],
"cinema4d": [],
"3dsmax": [],
"katana": [],
"revit": [],
"autocad": [],
"tbharmony": [],
"tbstoryboard": [],
"photoshop": [],
"aftereffects": [],
"indesign": [],
"illustrator": [],
"animate": [],
"premiere": [],
"flame": [],
"fusion": [],
"clarisseifx": [],
"unreal": [],
"substance": [],
"vegas": [],
"tdequalizer4": []
}
The key is the internal name of one of the supported applications ("cerebro", "maya", "nuke", "houdini" и т.д.), and the value is a string containing a protocol name or a list of protocol names. All key allows you to set the protocols for all possible programs at once, including Cerebro. If you need to specify an individual file access mode for any of the applications used, then you need to set your own protocol, different from the all one.
Note:
A value must be specified for the "cerebro" variable so that Cerebro application could independently determine which protocol it will use to access files. Otherwise, access to the file storage from Cerebro application will be denied. This is done to control access to your main file structure.
Possible protocol variable values for different applications:
network (default value) – used when working in the company's internal network; files are accessed directly in the network directory without being copied to the local directory;
local – used when working in the company's internal network; before file access is granted, files are copied to the local directory of the workstation;
cargador – used for remote work; access to files is granted via our Cargador service;
ftp – used for remote work; files can be accessed via the FTP protocol. Connection parameters are set by using a colon after the protocol name, for example,
"ftp:ftp://mycompany.com";s3 – used for remote work, access to files occurs via S3 API, cloud storage (Amazon S3, Google Cloud Storage, Yandex.Cloud Object Storage, etc). Connection parameters are set by using a colon after the protocol name, for example,
"s3:https://storage.yandexcloud.net/mycompany".git — working with files takes place in the Git version control system. To connect to repositories, use a colon after the protocol name, for example, "git:https://github.com/cerebro".
Important: To work with the Git protocol, the user's computer must have the Git client installed (https://git-scm.com/downloads).
Access protocol to remote repositories are supported http/https.
The description string follows this pattern:
"git:https://{remote git repository address}/{group name}/{repository name}:{working branch name}:{file working mode}"{remote git repository address}— is the address of the git repository where remote repositories are located.{group name}— is the name of the group the repositories belong to. The group can be omitted or contain subgroups, separated by a backslash.{repository name}— is the name of the Git repository. It can be specified in the protocol or in the project_path section for each project if you are using multiple repositories for different projects.{working branch name}— is the name of the branch in which work is being done. It can also be specified in both the protocol description and the project_path for each project.{file working mode}— is the mode in which Tentaculo works with files in the repository.Three working modes are supported:
version (default) — versioning occurs at the file level. When publishing a new version, a new file is created with the version number in the name (settings through file_path). For example, for the file photo_v01.jpg, the new version will be a new file photo_v02.jpg. In this mode, the entire project is fetched into the local repository, and only new version files are sent when publishing.
revision — the file version is determined by the revision in Git. Work is done with the same file, which is updated by the git commit command. In this mode, the entire project is fetched into the local repository, and only one file, which was being worked on, is sent when publishing.
project_revision — file versions, just like in revision mode, are determined by the revision in Git. The difference is that when publishing, all changes within the project are sent. This mode is needed for working with projects that involve changing many files at once when working with them.
You can set one or more protocols for each application, including Cerebro. For example, you might have a network drive that is accessible both on the local network and via FTP. In this case, you can set two protocols:
"cerebro": ["network", "ftp:ftp://mycompany.com"]
Additionally, when trying to access files, the user will be able to choose the protocol that suits him best – depending on where the user is at the moment, whether it's the office or a remote location.
Section project_path
The project_path variable contains a list of elements that describe the root paths to project files:
"project_path":
[
{
"project_name": "",
"task_activity": ""
"paths": []
}
]
Each of the elements describes possible file paths to the project's root directory and contains the following fields:
project_name – project name in Cerebro. If an empty string is specified as a value, then this structure contains default values for all projects that are not described in other list structures;
task_activity – the name of the activity. If the path leading to the root directory depends on it. For example, files for different types of activities can be stored on different servers. An empty value also means that the described paths are by default applicable to tasks containing any kind of activity;
paths – are the list of possible paths to the root directory. The path format depends on the protocol. Several paths can be set depending on access to the project repository from different remote work locations.
The project_name and task_activity variables are essentially the key to matching tasks in Cerebro, where files are uploaded or downloaded. And the paths variable determines where the files for this task should be located.
Path format in paths
Network protocol
For this protocol, paths are set in standard operating system formats. For example, if you need to set the root path for several operating systems, use multiple entries:
"paths":
[
"//server/projects", // for Windows
"/Volumes/projects", // for MacOs
"/server/projects" // for Linux
]
FTP protocol
For this protocol, use the prefix ftp://. The path is specified from the address indicated in the protocol, for example:
"paths":
[
"ftp://projects" // for FTP
]
Since users working on the same project may have different access methods, such as in a local network or remotely, multiple paths can be specified for various protocols that refer to the same location. For example, if projects in the local network are accessible via a network path and remotely via FTP, the paths can be written as follows:
"paths":
[
"ftp://projects", // for FTP
"//server/projects", // for Windows
"/Volumes/projects", // for MacOs
"/server/projects" // for Linux
]
S3 protocol
For this protocol, use the prefix s3://. The path is specified from the address indicated in the protocol, for example:
"paths":
[
"s3://projects" // for FTP
]
Note:
For cloud storage connected via the S3 API, the project_path is usually not required, as there are no actual folders in such storage, only tags that mimic them.
Git Protocol
For this protocol, use the prefix git://.
Path entry format:
"git://{repository_name}:{working_branch_name}:{file_working_mode}"
These are the same parameters that can be set in the git protocol, under the protocol section. If different repositories are used for different projects, they need to be defined in paths.
For example, for the myproject project, the repository myproject.git is used, with the working branch trunk and the working mode project_revision, meaning the entire project is updated as a whole.
"paths":
[
"git://myproject:trunk:project_revision" // for Git
]
Сargador protocol
For storage Cargador project_path is not required, as root access is determined by the storage itself.
Naming convention settings
Section file_path
The file_path variable contains a list of elements describing how tasks in different branches and projects match your file structure:
"file_path":
[
{
"folder_path": "",
"task_activity": "",
"name": "",
"name_editable": false,
"publish": "",
"version": "",
"ver_prefix": "",
"ver_padding": "",
"use_local": true,
"local": "",
"local_postfix": "local",
"publish_status": "",
"lock_in_progress": true
}
]
Each of the structures describes a set of subfolders and a file name template which are used to store file versions, and it contains the following fields:
folder_path – a formatted path in Cerebro to the beginning of the project branch (usually it is the name of the project or project section), where the rules described in this structure will be applied. If the value is an empty string, then this structure contains default values for all projects and branches not described in other structures on this list;
task_activity – the name of the activity type, if file naming depends on it. An empty value also means that the described parameters automatically apply to any activity tasks.
name (required field) – a formatted file name, can also be a list, for example "$(task_name)_foo", "$(task_name)_bar". In case there is a list of names, the user will be given an opportunity to choose one of the names;
name_editable (by default false) – indicates the possibility to manually specify the file name when adding it to the task. Possible values: true, false.
publish – a formatted path to the directory containing the main published version of the file. It is not required in Cargador because this storage has its own directory structure for file storing.
version – a formatted path to the directory containing file versions. Not required for Cargador storage.
ver_prefix – an additional element in the numbered version of a file name;
ver_padding (by default 3) – describes the number of characters in the version number;
use_local (by default true) – true/false value. It determines whether to create a local version or to operate directly in the versioned files. The local version is used by default;
local (by default same as publish) – a formatted path to the directory containing the local version of the file;
local_postfix (by default "local") . It allows you to change the default "local" postfix in your local versions;
publish_status – the task status name that will be used by default in the report publishing window.
lock_in_progress (default is true) – is true/false value. Determines whether to prevent work on a task when another user has already switched the status to "In Progress".
The folder_path and task_activity variables are, in fact, the key for task mapping in Cerebro, when files are either shared or downloaded. The rest of the variables determine where the files for this task should be located.
If the value of the publish or version field is not specified, then when the file is sent to the storage, the main or the numbered version of the file respectively will not be created.
Any components of the file_path variable can contain the following substitutable variables:
$(url[0]), $(url[1]) … $(url[i]) – the name of an individual element from the path to the selected task in Cerebro, where "i" is the nesting level of the element, starting from the project's root. For example, $(url[0]) is the name of the project, $(url[1]) is the name of the first level subtask, etc.;
$(soft_folder) – is an auxiliary variable that can be set in the soft_folder section, and which depends on the application used to create the files. It is used so that this variable can serve as a substitute in paths and file names;
$(task_name) – is the name of the selected task in Cerebro, i.e. the last element from the $(url[i]) list;
$(task_activity_name) - the name of the activity of the selected task in Cerebro;
$(task_path) – is the path leading to the selected task in Cerebro; it consists of all $(url[i]) elements, including the last one;
$(task_parent_name) – is the name of the parent task in relation to the selected one;
$(task_parent_path) – is the path to the parent task in Cerebro.
For substituted variables, there is the possibility of partial definition and support for regular expressions.
To highlight a part of a variable, use the syntax $ (variable_name [i: j]), where i and j are the starting and ending index in the string.
For example:
$(task_name[0:8]) — select part from position 0 to 8.
When the task name "modeling_main[0:8]" we get "modeling".
To highlight a part of a variable, you can also use regular expressions, while the first group from the regular expression is selected by searching for the first match in the string.
Syntax:
$(variable_name{/regexp/}), where regexp - regular expression.
For example:
$(task_parent_name{/_(.*)/})-— select the part after the character ‘_’.
When the parent task is named "asset_main{/_(.*)/}" we get "main".
In formatted strings, you can also use the operating system's environment variables if their names do not match the variables listed above. Their application format is the same: $(VARIABLE_NAME).
Section soft_folder
The value of the soft_folder variable is set depending on the application in which the files are created.
Element structure:
"soft_folder":
{
"maya": "",
"nuke": "",
...
}
The key in a set of paths is the internal name of one of the supported applications («maya», «nuke», «houdini» и т.д.), while the value is a string containing the variable value. It is used in the file_path section to specify file paths or file names, depending on the application in which the files are created.
Note:
Please, note that the keys do not list cerebro, since Cerebro application does not create files. When you share files using Cerebro application, the soft_folder value will be determined by the file extension corresponding to any of the supported applications.
Section version_save
The version_save variable defines what to do with the work file when saving the version — save, move, or always ask the user. The parameter can be defined for each app in which versions are saved.
Element structure:
"version_save":
{
"all": "",
"cerebro": "",
"maya": "",
"nuke": "",
...
}
Possible values:
"status_question" — ask the user if to save the work file when the status changes;
"copy" — always save the work file and copy it to where the version is stored;
"move" — always move the work file to where the version is stored;
"status_move" — move the work file to where the version is stored when the status changes;
"question" — always ask the user.
The default value is 'status_question'.
Section trans_mode
The trans_mode variable allows you to enable transliteration of file paths corresponding to tasks in Cerebro – depending on the application in which the files are created or shared.
Element structure:
"trans_mode":
{
"all": true,
"cerebro": true,
"maya": true,
"nuke": true,
...
}
Possible values: true, false. Transliteration is enabled by default.
When transliteration mode is enabled, all non-Latin characters in the file path are automatically converted to Latin characters, while spaces are converted into underscores («_»). For instance, instead of the /Project 01/Моделирование path, there will be used the /Project_01/Modelirovanie path.
Section casa_mode
The case_mode variable allows you to determine the case of letters of file paths corresponding to tasks in Cerebro, depending on the application in which files are created or uploaded.
Element structure:
"case_mode":
{
"all": "",
"cerebro": "",
"maya": "",
"nuke": "",
...
}
Possible value: "", "lowercase", "uppercase", "capitalize". The default value is empty. An empty value means that the case of letters in file paths will repeat the case of the corresponding tasks in Cerebro.
Section filters
he optional variable allows you to set task filtering parameters for each app.
You can set the following filters for each app:
"status_filter" — task filters in Todo List by statuses;
"activity_filter" — task filters in Todo List by activity type;
"tree_hide_list" — a list of tasks that need to be permanently hidden in Todo List and Browser.
Element structure:
"filters":
{
"all":
{
"status_filter": []
"activity_filter": []
"tree_hide_list": []
},
"maya": {},
"nuke": {},
...
}
status_filter – the variable allows you to set a list of statuses in order to filter tasks in Todo List. Standard filtering displays tasks in all statuses, except the stopped ones (work stopped). The variable type is an array of strings. In this filter, you can specify the filtering of tasks with no status by selecting the No Status option.
Example:
"status_filter": ["No Status", "ready to start", "in progress"]
activity_filter – the variable allows you to set a list of activities to filter tasks in Todo List. The variable type is an array of strings. In this filter, you can specify the filtering by tasks with no activity type by selecting the No Activity option.
Example:
"activity_filter": ["No Activity", "animation", "compose"]
tree_hide_list – the variable allows you to set a list of tasks hidden from the plugin users in Todo List and Browser tabs.
The variable type is an array of strings. Supported expressions:
{*} — any path element;
{?} — any character, except the path separator (/).
Example:
"tree_hide_list" : ["/Project 1/{*}/Shot{?}{?}/animation", "/{*}/Task {?}/Work"]
An example of setting up task filtering for the Maya app:
"filters":
{
"maya":
{
"status_filter": ["No Status", "ready to start", "in progress"],
"activity_filter": ["No Activity", "animation", "compose"],
"tree_hide_list": ["/Project 1/{*}/Shot{?}{?}/animation", "/{*}/Task {?}/Work"]
}
}
Section mirada_path
The optional variable allows you to specify the full path to the Mirada app for each operating system, providing the ability to add thumbnails for attached files of supported formats. By default, Tentaculo searches for Mirada in the directory of the installed Cerebro app.
Element structure:
"mirada_path":
{
"windows": "",
"linux": "",
"darwin": ""
}
Example:
"mirada_path":
{
"windows": "C:/Program Files/Cerebro/mirada.exe"
}
Section processor
The optional processors variable defines a set of python scripts that are additionally executed when performing actions in the plugin, such as opening a file, creating a new file in a task, saving a version, publishing a report (see the Processors section), and so on.