The Task Completion Widget provides a graphical bar chart to represent the progress of an item by the completion rate of its child tasks.
Name |
Task Completion Widget |
Common Title |
Task Completion Widget |
Class |
tactic.ui.table.TaskCompletionWdg |
TACTIC Version Support |
2.5.0 + |
Required database columns |
none |
This is a display-only widget. If all the tasks are completed for a shot, the bar reading would be 100%. Otherwise, a partial completion would be calculated based on tallying all the child tasks. If there are no tasks for the item, "No tasks" is displayed.
It is a common column that can be added using the Column Manager. The item name is "completion".
task_expr |
An expression to get to the tasks relative to the current sObject. e.g. @SOBJECT(prod/shot.sthpw/task) |
Example 1:
Let's say that we have a task in a pipeline with the following processes:
4 processes: Design, Rough, Modeling, Delivery
Let's say that for each process, there are:
4 statuses: Unassigned, In Progress, Ready_for_Review, Approved.
If the task is in the status: Unassigned, the task is 0% complete.
If the task is in the status: Started, the task is 33.3% complete.
If the task is in the status: Ready_for_Review , the task is 66.6% complete.
If the task is in the status: Approved, the task is 100% complete.
Let's say the task in the Rough process has the status 'Approved'. That means that is 100% complete for the Rough process. In the other 3 processes, it is at Unassigned, which is 0% complete.
Then, the TOTAL completion would be (1.0 + 0 + 0 + 0 ) / 4 = 25% complete.
Example 2:
Using the same process and task statuses, let's say the task in the Rough process has the status 'Ready_for_Review'. That means that is 66% complete for the Rough process. In the other 2 processes, it is at Started, which is 33.3% complete. In the last processes, it is at Unassigned, which is 0% complete.
Then, the TOTAL completion would be (0.666 + .333 + .333 + 0 ) / 4 = 33.3% complete. .
The Explorer Widget can be configured to launch Windows Explorer for Windows (or Finder for OSX). It can be configured to open to a directory which is either the sandbox or to the repository of the corresponding item.
Name |
Explorer |
Class |
tactic.ui.table.ExplorerElementWdg |
Category |
Common Columns |
TACTIC Version Support |
3.0+ |
Required database columns |
none |
When added to the view, the Explorer Widget button is represented as an icon of a folder. The button opens up Windows Explorer (or Finder on OSX). This gives the user a quick starting point for navigating to a directory that is relevant to the corresponding item. The convenience is greater when the repository contains a lot of items or the directory folder structure is very deep. Users save time by not having to navigate through endless directories to get to where they need to go to do work.
By default, the Explore Widget opens a window to the corresponding item if it exists in the user's sandbox.
mode |
sandbox|client_repo - determines what directory to go to when the explorer button is pressed. |
The following example configures the Explorer Widget to browse to the assets directory as specified in the Tactic Config File
<element name='explorer'> <display class='tactic.ui.table.ExplorerElementWdg'> <mode>client_repo</mode> </display> </element>
<element name='explorer'> <display class='tactic.ui.table.ExplorerElementWdg'/> </element>
This is the new preferred Check-in Widget for 3.7+. It makes use of the Java Applet to accomplish various kinds of check-in functions like checking in a single file, sequences of files, or directories. The copy or preallocate transfer mode should be used when dealing with a large file transfer. Upload transfer mode only supports checking in single files and sequences of files. Upload is set to be the default in case new users do not have the handoff directory readily set up.
Name |
General Check-in Widget |
Class |
tactic.ui.widget.CheckinWdg |
Category |
Widget |
Supported Interfaces |
TableLayoutWdg |
TACTIC Version Support |
3.7.0 + |
Required database columns |
none |
transfer_mode |
upload, copy and move are supported. copy is recommended for most situations when users are usually granted only read access to the TACTIC asset repo. (default is copy) |
mode |
sequence, file, dir, and add are supported. sequence is for file sequence checkin; file is for single file checkin; dir is for directory checkin; and add is for appending file or dir to an existing snapshot. If not specified, multiple selections will be available for the user to choose. Note: upload transfer mode only supports single file or file sequence checkin. |
checkin_script_path |
a custom checkin script path to specify an override on what functions get called during a checkin. Note: If trying to do some preprocessing with the file or directory before checking in, just make use of validate_script_path function using Client Trigger. Client Trigger works by setting up this check-in script as a Client Trigger callback that affects the search type rather than just a column definition. |
validate_script_path |
a script path pointing to a JavaScript file that is run before the actual checkin. If it throws an error using "throw(<error message>)", the checkin will not initiate. This path can also use it to run some client-side preprocessing of the file or directory. It is not set up as a display option but rather as a Client Trigger callback. |
checkout_script_path |
a custom check-out script path to specify to override what happens during a check-out. |
process |
If set, the process specified will be pre-selected when the General Check-in Widget is drawn, |
lock_process |
If set to true, the user will not be able to choose a different process during a checkin, in the General Check-in Widget |
show_context |
When set to true, the context will be displayed to the user. (default is false) |
The Gear Menu in the Check-in Widget provides the following administration options:
Edit Process | Load the process options pop-up. The process and subcontext options are described further in the sections below |
List Processes | List all of the processes for the current pipeline. This provides the same access to the as the Edit Process option but for all processes. |
Show Server Transaction Log | Show the standard server transaction log |
Undo Last Server Transaction | Undo the last transaction. When undoing a checkin, the files will also be removed in the file system. |
Redo Last Server Transaction | Redo the last transaction. When redoing a checkin, the files will be restored in the file system. |
The default settings will allow a user to check in files to an assets in the "publish" process. It provides a very general and loosely enforced workflow to check in and manage files. Often, it is required, that a particular process has very strict enforcement of naming conventions and check-in procedures.
The General Check-in widget is highly configured and can be tuned precisely for each part of the process. The various customizations can fall into the following categories:
Validation |
Subcontext options |
Custom interface |
Custom check-in script |
Naming conventions |
Each of these can be customized for the particular widget or at the process level.
Validation is a custom script that will is run before the check-in process occurs. It provides the ability to check that all files in the checkin conform to some custom logic required for a successful checkin. If the validation script fails, then the entire checkin is aborted.
A client trigger set up allows control over what check-in script or validate_checkin script to call during a checkin. Here is an example of how to set the checkin/validate_folder script to run before the check in of prod/asset. The event name is CheckinWdg|validate_script_path|<search_type>. If only a particular process is desired to be run on check in for, like "texture", the event name would become CheckinWdg|validate_script_path|prod/asset|texture. To override the checkin_script_path, use the event CheckinWdg|checkin_script_path|<search_type>. If this event-based set-up seems a bit too involving, override the checkin_script_path for just this instance of the widget by using the standard display option <checkin_script_path>.
By default, the subcontext selection is set to (auto). It is the simplest to use and allows TACTIC to auto generate the subcontext. Because the subcontext is auto generated, strict naming conventions for the file are often sacrificed for ease of use. By default, the checked in file will just have a version number attached to it.
It is possible to force a limited list of subcontext options on a particular checkin. This means that the files checked in will be named according to the subcontext selected and provides a limited set of approved containers in which files can be checked in.
Checkin's are always categorized by process. If there is no pipeline defined, the default process "publish" will be used. Categorizing checkin's by the process in the pipeline of an asset organizes the work done for an asset according to its product life cycle.
Another important attribute of a checkin is the context. Assets are versioned according to their context which provide a namespace for versioning checkin's of an asset. All checkin's of an asset with the same context are versioned together. The context of an asset is a particular way to view an asset.
For example, a 2D drawing of a character and a 3D model of the same character represent the same abstract asset, so are two different contents of the asset. This can be implemented in TACTIC by specifying the following in the Check-in Widget's Context Options:
Context Options: 2D_drawing|3D_model
Although the context can be any string, most often, it is built up from other parameters. The convention usually used is "<process>/<subcontext>". All of TACTIC's built-in check-in tools assume this relationship. The subcontext provides a namespace for checking in multiple subcategories of files within a single context.
The following is an example of these subcontext options:
Subcontext Options: hi|med|low
Naming conventions are often strictly enforced, meaning that the folder and the file name are automatically supplied on check in of a file to the central repository.
In the panel on the right, when something from the list is selected for check in, the corresponding Check-in type (e.g.. file, directory, sequence, multiple individual files) is automatically selected by the Check-in Widget.
For example, on the panel on the right, if a file is selected for check in, the Check-in type will automatically switch to A File under the Check-in Options on the bottom left:
For example, if a folder is selected to check in on the right panel, the Check-in type will automatically switch to A Directory under the Check-in Options on the bottom left:
Example 1)
To check in high resolution and low resolution files for a model process, first specify the context_options under:
Checkin Widget -> Gear Menu -> Edit Process:
Specify the following Context Options:
Context Options: model/hi|model/lo
OR specify the following Subcontext Options:
Subcontext Options: hi|lo
Both of the choices above give the same result.
Result:
process = model context = model/hi (or model/lo)
Only use either the context field or the subcontext field but not both fields.
If values are specified for both the context_options and the subcontext_options, only the context_options will be used (the subcontext_options will be ignored).
Example 2)
To provide the same options (hi and lo) and avoid using subcontexts specify the following context_options:
context_options: model_hi|model_lo
Result:
process = model context = model_hi (or model_lo)
Notice that the forward slash '/' was not used, which avoids using subcontexts.
Example 3)
The following is another example of how to avoiding using subcontexts altogether.
To check in a proxy and a staging context for a model process, specify the following context_options:
context_options: model_proxy|model_staging
Result:
process = model context = model_proxy (or model_staging)
Again, notice that the forward slash '/' was not used, which avoids using subcontexts.
The following subcontext option keywords are supported:
(auto) |
Uses the filename as the subcontext (auto is the default if no values are specified for the context or subcontext options) |
(main) |
Uses the process as the context |
(text) |
Allows the user to specify their own context for the file to check in |
Example for (auto):
process: |
design |
filename: |
my_checkin_file.txt |
subcontext option selected: |
(auto) |
Result:
context = design/my_checkin_file.txt
Example for (main):
process: |
design |
subcontext option selected: |
(main) |
Result:
context = design (because design is the process)
Example for (text):
To check in different colors of a car for the design process eg. a green version of the car and a red version
process: |
design |
subcontext option selected: |
(text) |
custom context inputted | green |
Result:
context = design/blue
A custom layout view can be provided in the check-in panel as options.
For example, to provide check boxes during the check in to submit the job to the render farm or to submit the file for the review process, create a custom view and specify the view in the Check Options View.
To do this, first, create a custom view under:
Admin Views -> Project -> Widget Config
Below is an example of a custom layout view:
note:
In the example custom view above, to make use of these custom UI check boxes, more work needs to be done to override the checkin_script or checkin_validate_script.
The checkin_script and the checkin_validate script can be found under: Checkin Widget -> Gear Menu -> List Processes
Example validate scripts can be found at the end of this Check-in Widget doc in the section labeled Example Scripts: Example 1 and 2.
Then, specify the name of the view under:
Checkin Widget -> Gear Menu -> List Processes
In the Check-in Options View, specify the name of the custom layout view for the check-in options:
Finally, select a file to check in, the custom view with the check-in options will appear on the panel on the left.
Without custom check-in options: | With customer check-in options: |
|
![]() |
This script can be saved in the Script Editor accessible through the Gear Menu.
Example 1: checkin/validate_folder
var values = bvr.values; var file_path = values.file_paths[0]; var sk = values.search_key; var applet = spt.Applet.get(); var file_list = applet.list_dir(file_path); for (var i=0; i <file_list.length; i++){ var base =spt.path.get_basename(file_list[i]); if ( base == 'DATA') { throw('it contains a DATA folder. Checkin aborted'); } }
Example 2: checkin/validate_file
var values = bvr.values; var file_path = values.file_paths[0]; var sk = values.search_key; var applet = spt.Applet.get(); var base =spt.path.get_basename(file_path); if ( base.test(/\\.mov$/)) { throw('it does not have a mov extension. Validation failed.'); }
Example 3: Custom checkin_script using display option "checkin_script_path". The default snapshot_type is file, if the file extension is .mov, the snapshot_type is set to 'mov'.
var file_paths = bvr.values.file_paths; var description = bvr.values.description; var search_key = bvr.values.search_key; var context = bvr.values.context; var transfer_mode = bvr.values.transfer_mode var is_current = bvr.values.is_current; var path = file_paths[0] spt.app_busy.show("File Checkin", path); var snapshot_type = 'file'; if (path.test(/\\.mov$/)){ snapshot_type = 'mov'; } var server = TacticServerStub.get(); snapshot = server.simple_checkin(search_key, context, path, {description: description, mode: transfer_mode, is_current: is_current, snapshot_type:'mov'});
The General Check-in Widget is usually invoked with a CheckinButtonElementWdg with a transfer mode specified. In this implementation, the process will be preselected as "texture", providing the pipeline for this sObject does contain a process named 'texture'.
<element name='general_checkin' title=' '> <display class='tactic.ui.widget.CheckinButtonElementWdg'> <transfer_mode>copy</transfer_mode> <process>texture</process> </display> </element>
In this implementation, the process will be preselected as "model", providing the pipeline for this sObject does contain a process named 'model'. The user cannot switch to other processes in the pipeline, and only "New Directory" mode can be selected.
<element name='general_checkin' title=' '> <display class='tactic.ui.widget.CheckinButtonElementWdg'> <transfer_mode>copy</transfer_mode> <process>model</process> <lock_process>true</lock_process> <mode>dir</mode> </display> </element>
The Checkin History Widget is a toggle that opens a hidden row that displays all the snapshots (snapshots are checkins at a particular moment in time for a context) for an item.
Name |
Checkin History Widget |
Common Title |
History |
Class |
tactic.ui.widget.SObjectCheckinHistoryWdg |
Category |
Common |
TACTIC Version Support |
3.0.0 + |
Required database columns |
none |
The following details are displayed by the Checkin History Widget for a task:
preview of the snapshot
whether checkout of the snapshot is locked
toggle to open a hidden row to list the files in the snapshot
link to checkout this particular snapshot
context of the snapshot
version of the snapshot
revision of the snapshot
login who checked in the snapshot
timestamp of the checkin
description written by the user at the time of the snapshot
indicator whether the snapshot is the current version for that context
toggle to open the notes using the Note Sheet Widget
The Checkin History Widget can be found as a common column that can be added using the Column Manager.
The Notes Widget allows users to write notes for a particular item (sObject). This widget allows team members to exchange comments for a process by writing them in the Notes Widget. The notes are displayed chronologically with latest one appearing at the top. The complete history is displayed by default. It's one of the common columns which can be added in any view for an sType. A similar note entry widget called the Note Sheet Widget, focuses more on the speed of entry rather than the display of the conversation.
Name |
Notes |
Class |
tactic.ui.widget.DiscussionWdg |
Category |
Table Element Widget |
Supported Interfaces |
TableLayoutWdg |
TACTIC Version Support |
2.5 + |
Required database columns |
This widget interacts with the built in sthpw/note table |
To create a new note, select the New Note button.
This will switch the DiscussionWdg into insert mode where notes and context of the notes can be entered.
In most cases, the grouping for the notes is derivived through selecting a 'context'. This context is often chosen in relation to the context of a given 'task' or 'snapshot' (Checkin) for the same parent SObject. This then assoociates all tasks, notes and snapshots under a specific Search Object. This allows users to retrieve histiorical data for a Search Object through a context. This answers the question "What's the history of this Asset from the design department?"
To navigate the history of the notes, click on a particular note and it will expand and display the full note.
Depending on the configuration, the goupping (context) items will be grouped and separated by a group label represented as << label >>. In that case, selecting the group label will trigger a warning popup.
To unset a value, you can usually select the empty value with the label '-- Select --'.
The Notes widget is a common column which can be added using the Column Manager. The item name is "notes". A "default" context is used in this simple implementation.
context |
a global context can be specified |
append_context |
a context can be appended to the current list (deprecated) |
setting |
A project setting can be used to drive the contexts. This provides the key of the project setting. |
append_setting |
This serves the same purpose as setting but would append the contexts at the end |
include_submission |
If set to true, it would include the notes for the submission (a child) of the current sobject. |
The Note Sheet Widget allows entering of many notes in different contexts and different parents at the same time. It can be used for entering notes for any search types. By default, it uses the parent's pipeline processes as the contexts for note entry. Notes can be saved either individually or altogether. There is an option to make a note private as well.
Name |
Note Sheet Widget |
Common Title |
Note Sheet |
Class |
tactic.ui.app.NoteSheetWdg |
Category |
Table Element Widget |
Supported Interfaces |
TableLayoutWdg |
TACTIC Version Support |
2.5.0 + |
Required database columns |
none |
When used with regular sTypes with its pipeline_code set, the Note Sheet Widget automatically displays the pipeline processes as note context options. Each enabled context is marked with a check in the check box, which goes along with a text box for note entry. Indicate which contexts display for input by selecting the appropriate check boxes. When used with a child search_type like a task, the Note Sheet Widget assumes its context attribute as the note context.
Clicking on "save" icon will save all of the notes together for this parent. To save one note at a time, click on the individual save button under the corresponding note.
The private check box turns a note access as private if checked. The history button is used to display all the note entries for a context.
dynamic_class |
Set the class name of the widget to be displayed |
pipeline_code |
Specifies a particular pipeline_code to use or if the parent of this note sheet widget does not have the 'pipeline_code' attribute e.g. 'model'. If unspecified, it will be based on the pipeline_code value of its parent. |
element_class |
To override the default element class NoteTableElementWdg, modify the look or add extra buttons to the UI to enter notes. One method is just to override the method get_action_wdg() |
use_parent |
When a note sheet is added to a sType like task or snapshot but it is set up so that the note is targeted at its parent, which could be an asset or shot. If so, set this display option to true. |
append_context |
Used to add contexts that are not defined in the pipeline. Separate the contexts with a pipe character if there are more than one, e.g. producer|director. |
The Thumbnail Widget is available for most types by default as the preview tool for images which have been uploaded for preview and thumbnail purposes. An icon for the corresponding file type is displayed for non-image files.
Name |
Thumbnail Widget |
Common Title |
Preview, Snapshot, Files |
TACTIC Version Support |
2.5.0 + |
Required database columns |
none |
script_path |
Specify a script to control what UI it draws or what happens when the user click on the preview icon. Refer to it by this script path. |
detail_class_name |
Specify the default behavior to open up a pop-up window but just with a different widget written in Python. |
icon_context |
The context that the widget displays |
icon_size |
Control the icon size by percentage (up to 100%) e.g. 30% |
min_icon_size |
Minimum icon size (in pixels). |
latest_icon |
If set to 'true', the icon displayed corresponds to the latest checkin in the checkin history. It will disregard the icon context designated for this search type. |
filename |
If set to 'true', the file name of the linked file is displayed under the icon. |
original |
If set to 'true', the link will point to the original file with the 'main' file type checked in. Otherwise the scaled down 'web' version of the file will be linked. This is only applicable to image-type files where an icon has been generated during a check-in. |
file_type |
Whether to display the file type for download or not. |
detail |
If set to 'false', clicking of the thumbnail will link the underlying picture instead of displaying the single asset view in a pop-up |
protocol |
'http'(default) or 'file'. The protocol under which the thumbnail link will open when being clicked on. When 'file' is set, the default application is usually Windows explorer or at times Internet Explorer. 'file' mode can alleviate the bandwidth usage on the web server when viewing large media files like Quick Time. |
redirect_expr |
Works similarly as the redirect but in the form of expression. e.g. @SOBJECT(prod/sequence). If this display option is set for the ThumbWdg for prod/shot, it will display the icon of its sequence instead. |
The Task Edit Widget is a toggle that opens a hidden row that displays all the tasks for an item. If there are multiple processes for an item, the tasks for those processes will be displayed.
Name |
Task Edit |
Common Title |
Tasks |
Class |
tactic.ui.panel.TableLayoutWdg |
Category |
Table Layout Widget |
Supported Interfaces |
TableLayoutWdg |
TACTIC Version Support |
3.0.0 + |
Required database columns |
none |
The following details are displayed by the Task Edit Widget for a task:
a link to the task's Work Area (where the Checkin and Checkout tools can be found)
the task's description
status for that process
the user assigned to the process
the supervisor of that process
the priority
start and end date for the process in the form of a Gantt chart
There are no options provided for the Task Edit Widget.
The Task Schedule displays a horizontal bar graph representing the schedule of start/end date and duration for all tasks assigned to an item. This widget is a simple pre-configuration of the Gantt Chart widget.
Name |
Task Schedule |
Class |
tactic.ui.table.GanttElementWdg |
Category |
Common Columns |
TACTIC Version Support |
3.0+ |
Required database columns |
none |
The Task Schedule Widget is a common column that can be added using the Column Manager.
The following is the configuration option which the makes this widget distinct from its derivative, the Gantt Chart widget.
[ { "start_date_expr": "@MIN(sthpw/task.bid_start_date)", "end_date_expr": "@MAX(sthpw/task.bid_end_date)", "color": "#33F", "edit": "true", "default": "false" }, { "start_date_expr": "@MIN(sthpw/task['context','model'].bid_start_date)", "end_date_expr": "@MAX(sthpw/task['context','model'].bid_end_date)", "color": "#F0C956", "edit": "true", "default": "false" } ]
Show Title |
True or False Display the title in the column header. |
Date Mode |
visible, hover Always display the start/end date next to the horizontal bar or display the dates only on cursor hover. |
Range Start Date |
Select the start date range for the tasks to display. |
Range End Date |
Select the end date range for the tasks to display. |
Show Milestones |
task, project Display a red vertical bar representing the milestone for the task or the project |
Year Display |
none, default Display the year in the column header. |
Week Display |
none, default Display the week in the column header. |
<element name="task_schedule"> <display class="tactic.ui.table.GanttElementWdg"> <options>[ { "start_date_expr": "@MIN(sthpw/task.bid_start_date)", "end_date_expr": "@MAX(sthpw/task.bid_end_date)", "color": "#33F", "edit": "true", "default": "false" }, { "start_date_expr": "@MIN(sthpw/task['context','model'].bid_start_date)", "end_date_expr": "@MAX(sthpw/task['context','model'].bid_end_date)", "color": "#F0C956", "edit": "true", "default": "false" } ]</options> </display> <action class="tactic.ui.table.GanttCbk"> <sObjects>@SOBJECT(sthpw/task)</sObjects> <options>[ { "prefix": "bid", "sObjects": "@SOBJECT(sthpw/task)", "mode": "cascade" }, { "prefix": "bid", "sObjects": "@SOBJECT(sthpw/task['context','model'])", "mode": "cascade" } ]</options> </action> </element>
The Task Status Edit column is used to display the status of all tasks for the item. It also provides conveniences such as changing the status of the task and the assigned user.
Name |
Task Element Widget |
Common Title |
Task Status Edit |
Class |
tactic.ui.table.TaskElementWdg |
Category |
Common Columns |
TACTIC Version Support |
3.0.0 + |
Required database columns |
none |
Once this column is added into the view, the drop down list can be used to change the status. In addition, this column also displays the process, schedule and the assigned user.
This widget can be added using the Column Manager and can be found under the common columns as Task Status Edit.
TACTIC provides the ability to assign each status its own color. Setting colors is handles from the Project Workflow (Pipeline) editor. Each process in a regular pipeline or a status pipeline can be assigned a color which will be used in this widget.
Bg Color |
status and process. Set what controls the background color of the task. Status sets the task color to be the same as the status color. Process mode sets the task color to be the same color of the process as set in the Workflow Editor. |
Status Color |
status and process. Set what controls the background color of the status drop down. Status sets the status drop down color to be the same as the status color. Process mode sets the status drop down color to be the same color of the process as set in the Workflow Editor. |
Context Color |
status and process. Set what controls the background color of the context grid. Status sets the context grid color to be the same as the status color. Process mode sets the context grid color to be the same color of the process as set in the Workflow Editor. |
Text Color |
Specifies the color of the task text using a color swatch. |
Show Process |
True or false. Displays the process of the task within the column. |
Show Context |
True or false. Displays the context of the task within the column. |
Show Dates |
True or false. Displays the time frame for the task. The schedule will display the start and end date. |
Show Assigned |
True or false. Displays the assigned user to the task. |
Show Track |
True or false.. Displays a button on each task which displays the last status and the user who changed it. |
Show Labels |
True or false. Displays the label of the pipeline's process. |
Show Border |
all, one-sided, none. All displays a border around each task. One-sided displays a border around one one side of the task. None hides the border. |
Show Current Pipeline Only |
True or false. Displays tasks for the current pipeline only. |
Show Task Edit |
True or false. Displays a button which pops-up a window to edit the task info. |
Task Edit view |
Specify the Task view by which to edit the task information. |
Task Filter |
panel, vertical, horizontal: Layout orientation to display the list of tasks. |
Layout |
context only or process only: Displays only tasks for either the context or the process. |
Edit Status |
True or false. Allows the user to open the status drop down selection box for the status to change it. |
Edit Assigned |
True or false. Allows the user to open the status drop down selection box for the assigned user to change it. |
The Task Status History is a toggle that opens a hidden row that displays all the status changes for an item. If there are multiple processes for an item, the status updates for those processes will be displayed.
Name |
Task Status History |
Class |
tactic.ui.panel.TableLayoutWdg |
Category |
Common Columns |
TACTIC Version Support |
3.0+ |
Required database columns |
none |
<element name="task_status_history"> <display class="HiddenRowToggleWdg"> <dynamic_class>tactic.ui.panel.TableLayoutWdg</dynamic_class> <search_type>sthpw/status_log</search_type> <view>table</view> <expression>@SOBJECT(sthpw/task.sthpw/status_log)</expression> <mode>simple</mode> </display> </element>
The Work Element Widget is used for accessing the checkin and checkout tool needed to handle a task assigned. After a task is assigned, an artist can go to the "My Tasks" or any other task page where there is a "Work" column which will expand to this widget. You can carry out serveral typical functions related to check-in and check-out in the sub tabs that open. You can even customize what tabs are opened when the work button is clicked on.
Name |
Work |
Class |
tactic.ui.table.WorkElementWdg |
Category |
Table Element Widget |
Supported Interfaces |
TableLayoutWdg |
TACTIC Version Support |
3.5.0 + |
Required database columns |
none |
When clicked on, it opens up a new Work area tab with 3 sub tabs underneath which comprise all the functions an artitst would need when assigned a task. He can enter notes, change task status, review check-in history, check in, and check out files.
The General Check-in Widget appears in the Check-in sub tab. You can click "Browse" here to select the file to be checked in. The is_current checkbox in Options can be used to make a snapshot current on checking in. The link checkbox, when checked, links the sandbox directory to the process tied to the task. It makes it easy for an artist to jump to a different process and checks out their snapshots into the current sandbox associated with the task. Otherwise, if you check out a file from the model process, it will be copied to the model sandbox folder.
checkout_panel_script_path |
Deprecated in 3.5. Use the tab_config_<> method to set up custom checkout tab |
checkout_script_path |
A custom check-out script path you can specify to override the default check-out script. The default check-out script checks out everything under the selected snapshot. Refer to Example 4. |
validate_script_path |
A script path pointing to a JS script that is run before the actual check-in. If it throws an error using "throw(<error message>)", the check-in will not initiate. You can also use it to run some client-side preprocessing of the file or directory. |
transfer_mode |
Upload, copy, move, preallocate are supported. 'preallocate' can only be used if the client machine has direct disk write access to the TACTIC asset repo. It skips the need to hand off the files in the handoff directory. 'copy' is recommended for most situation when users are usually granted only read access to the TACTIC asset repo. |
mode |
Sequence, file, dir, and add are supported. 'sequence' is for file sequence checkin; 'file' is for single file checkin, 'dir' is for directory checkin and 'add' if for appending file or dir to an existing snapshot. If not specified, multiple selections will be available for the user to choose. Note: upload transfer mode only supports single file or file sequence check-in. |
checkin_panel_script_path |
Deprecated in 3.5. Use the tab_config_<> method to set up custom checkin tab |
checkin_script_path |
A custom checkin script path you can specify to override the default check-in script. This can be used in conjunction with the validate_script_path. |
process |
If set, the process specified will be pre-selected when the General Checkin Widget is drawn, |
lock_process |
If set to true, the user will not be able to choose a different process during check-in on the General Checkin-in Widget |
checkin_relative_dir |
If specified, e.g. WIP, it is appended to the current sandbox directory and preselcted as the directory to be checked in. It's applicable to Direcotry-type checkin |
checkin_ui_options |
It applies to the check-in options of the CheckinWdg. Supported attribute at the moment is "is_current" e.g. {"is_current":"false"} would make all check-ins non-current. {"is_current":"optional"} would make the checkbox unchecked by default. Not specifiying it would render the option available to the user to choose at the check-in time. |
show_versionless_folder |
If set to true, it displays the latest and current versionless folders. |
The following defines the default "Work" element. It looks a bit complicated but in most cases, you would just need to simply change the different options available through "Edit Column Definition":
<element name="work" title="Work on Task"> <display class="tactic.ui.table.WorkElementWdg"> <transfer_mode>upload</transfer_mode> <cbjs_action> var tbody = bvr.src_el.getParent(".spt_table_tbody"); var element_name = tbody.getAttribute("spt_element_name"); var search_key = tbody.getAttribute("spt_search_key"); var checkin_script_path = bvr.checkin_script_path; var checkin_ui_options = bvr.checkin_ui_options; var validate_script_path = bvr.validate_script_path; var checkout_script_path = bvr.checkout_script_path; var checkin_mode = bvr.mode; var transfer_mode = bvr.transfer_mode; var sandbox_dir = bvr.sandbox_dir; var lock_process = bvr.lock_process; var server = TacticServerStub.get(); var code = server.eval( "@GET(parent.code)", {search_keys: search_key} ); spt.tab.set_main_body_tab(); spt.tab.add_new(); var kwargs = { 'search_key': search_key, 'checkin_script_path': checkin_script_path , 'checkin_ui_options': checkin_ui_options , 'validate_script_path': validate_script_path , 'checkout_script_path': checkout_script_path, 'mode': checkin_mode , 'transfer_mode': transfer_mode, 'sandbox_dir': sandbox_dir, 'lock_process': lock_process } var title = "Task: " + code; var class_name = "tactic.ui.tools.sobject_wdg.TaskDetailWdg"; spt.tab.load_selected(search_key, title, class_name, kwargs); </cbjs_action> <icon>WORK</icon> </display> </element>
The following defines a different usage of it using copy trasnfer mode, a custom checkout script and a custom validating checkin script. The value of the two script paths are the script_path you have saved in the Script Editor. lock_process is set to false. To enable these options, you can do it in the context menu "Edit Column Definition" and set the following:
checkout_script_path: checkout/all_processes validate_script_path: checkin/validate_frames transfer_mode: copy lock_process: false
The following shows a way to customize what the small check-out button does in the checkout_tool view. In widget config, we will set the column definition for the element checkout for the "sthpw/snapshot" search type. It can be accessed through "Edit Column Definition".
checkout_script_path: checkout/checkout_tool_script
Example 1: checkin/validate_frames
var values = bvr.values; var file_path = values.file_paths[0]; var sk = values.search_key; var applet = spt.Applet.get(); var file_list = applet.list_dir(file_path); var server = TacticServerStub.get(); var st = 'prod/shot'; var shot = server.get_by_search_key(sk); var frame_count = parseInt(shot.frame_count, 10); for (var i=0; i <file_list.length; i++){ var base =spt.path.get_basename(file_list[i]); if ( base == 'FRAMES') { var frames = applet.list_dir(file_list[i]); if (frames.length != frame_count) { throw('Frames length in FRAMES [' + frames.length + '] folder does not match shot\'s frame count'); } } }
Example 2: checkout/all_processes. It illustrates how to implement a custom check-out that only checks out a portion of what has been checked in.
//back up the Work-in-progress folder function backup_WIP(bvr) { var sandbox_dir = bvr.sandbox_dir; var applet = spt.Applet.get(); var found_WIP = false; var dirs = applet.list_dir(sandbox_dir, 0); for (var k=0; k < dirs.length; k++){ if (/WIP$/.test(dirs[k])){ found_WIP = true; break; } } if (!found_WIP) { alert('WIP folder not found. Backing up of WIP folder aborted') } else { var server = TacticServerStub.get(); var folder = spt.path.get_basename(sandbox_dir); var date_obj = new Date(); var suffix = date_obj.getFullYear().toString() + spt.zero_pad((date_obj.getMonth() + 1).toString(), 2) + spt.zero_pad(date_obj.getDate().toString(), 2) + '_' + spt.zero_pad(date_obj.getHours().toString(), 2) + spt.zero_pad(date_obj.getMinutes().toString(),2); var parts = sandbox_dir.split(/[\/\\]/); sandbox_dir = sandbox_dir + '/WIP'; var backup_dir = parts.join('/') + '/WIP' + '_' + suffix; applet.copytree(sandbox_dir, backup_dir); //remove the contents of WIP applet.rmtree(sandbox_dir); applet.makedirs(sandbox_dir); } } // just checkout a subfolder named REF. if it's not found, just check out the // first subfolder function checkout_snapshot_table(bvr){ var top = bvr.src_el.getParent(".spt_checkin_top"); var table = top.getElement(".spt_table"); var search_keys = spt.dg_table.get_selected_search_keys(table); if (search_keys.length == 0) { alert('Please check the checkbox(es) to check out a version.'); } else if (search_keys.length > 1) { alert('Please check only 1 checkbox at a time. Multi-selection is' + ' only supported for Full Check-out Selected in the Gear menu.'); return; } spt.app_busy.show("Custom Check-out snapshots", "Copying to Sandbox..."); var server = TacticServerStub.get(); var top = bvr.src_el.getParent('.spt_checkin_top'); var sandbox_input = top.getElement('.spt_sandbox_dir'); if (sandbox_input) bvr.sandbox_dir = sandbox_input.value; for (var i =0; i < search_keys.length; i++) { checkout_snapshot(bvr, search_keys[i]); } spt.app_busy.hide(); } function checkout_snapshot(bvr, snapshot_key, downlevel) { var server = TacticServerStub.get(); try { var paths = server.get_all_paths_from_snapshot(snapshot_key); //var sandbox_dir = server.get_client_dir(snapshot_key,{mode:'sandbox'}); var sandbox_dir = bvr.sandbox_dir; var applet = spt.Applet.get(); for (var i = 0; i < paths.length; i++ ) { var path = paths[i]; var parts = path.split(/[\/\\]/); var dirs = applet.list_dir(path); var tar_dir = ''; for (var j=0; j < dirs.length; j++) { if ((/REF/i).test(dirs[j])) tar_dir = dirs[j]; } //just take the first one if REF is not found if (!tar_dir) { alert('REF not found. First subfolder is checked out'); tar_dir = dirs[0]; } var folder = spt.path.get_basename(tar_dir); var new_path = path + '/' + folder; var sand_paths = applet.list_dir(sandbox_dir, 0); for (var j=0; j< sand_paths.length; j++) { var dst_folder = spt.path.get_basename(sand_paths[j]); if (dst_folder == 'REF') { alert('REF folder already exists in [' + sandbox_dir + '] Please rename or remove it first.'); return; } } // the applet can decide between copy_file or copytree applet.copytree(new_path, sandbox_dir + "/" + folder); } } catch(e){ alert(spt.exception.handler(e)); } } backup_WIP(bvr); var down_level = 1; checkout_snapshot_table(bvr, down_level);
Example 3: Custom Checkout button callback passing a specific script for the Check-out Widget popup using display option "checkout_panel_script_path"
var class_name = 'tactic.ui.widget.CheckoutWdg'; var values = bvr.values; var search_key = values.search_key; var sandbox_dir = values.sandbox_dir; var process = values.process; var options = { 'show_publish': 'false', 'process': process, 'search_key': search_key, 'checkout_script_path': 'checkout/custom_checkout', 'sandbox_dir': sandbox_dir }; var popup_id ='Check-out Widget'; spt.panel.load_popup(popup_id, class_name, options);
Example 4: Custom check-out script for the small check-out button in the checkout_tool view. This can be used to customize a quick-checkout for the latest or current snapshot without opening the Check-out popup widget, using display option "checkout_script_path"
function checkout_snapshot(bvr) { var values = bvr.values; var snapshot_key = values.search_key; var context = values.context; var server = TacticServerStub.get(); // get the files for this snapshot, always get the latest // instead of relying on the last snapshot when the UI was drawn try { var paths = server.get_all_paths_from_snapshot(snapshot_key); //var sandbox_dir = server.get_client_dir(snapshot_key,{mode:'sandbox'}); // This one comes from values as the sandbox_dir is determined by // the snapshot only var sandbox_dir = values.sandbox_dir; var applet = spt.Applet.get(); for (var i = 0; i < paths.length; i++ ) { var path = paths[i]; var parts = path.split(/[\/\\]/); var dirs = applet.list_dir(path); var tar_dir = ''; for (var j=0; j < dirs.length; j++) { if ((/REF/i).test(dirs[j])) tar_dir = dirs[j]; } //just take the first one if REF is not found if (!tar_dir) { alert('REF not found. First subfolder is checked out'); tar_dir = dirs[0]; } var folder = spt.path.get_basename(tar_dir) var new_path = path + '/' + folder; var sand_paths = applet.list_dir(sandbox_dir, 0); for (var j=0; j< sand_paths.length; j++) { var dst_folder = spt.path.get_basename(sand_paths[j]); if (dst_folder == 'REF') { alert('REF folder already exists in [' + sandbox_dir + '] Please rename or remove it first to avoid mixing files.'); return; } } // the applet can decide between copy_file or copytree applet.copytree(new_path, sandbox_dir + "/" + folder); } } catch(e){ alert(spt.exception.handler(e)); } } checkout_snapshot(bvr);
Example 5: Custom checkin_script using display option "checkin_script_path". The default snapshot_type is file, if the file extension is .mov, the snapshot_type is set to 'mov'.
var file_paths = bvr.values.file_paths; var description = bvr.values.description; var search_key = bvr.values.search_key; var context = bvr.values.context; var transfer_mode = bvr.values.transfer_mode var is_current = bvr.values.is_current; var path = file_paths[0] spt.app_busy.show("File Checkin", path); var snapshot_type = 'file'; if (path.test(/\\.mov$/)){ snapshot_type = 'mov'; } var server = TacticServerStub.get(); snapshot = server.simple_checkin(search_key, context, path, {description: description, mode: transfer_mode, is_current: is_current, snapshot_type:'mov'});
The Work Hours widget provides an interface to record the number of work hours spent for each task. The break down of the work hours by task allows the analysis to be broken down at the lowest level of detail.
Name |
Work Hours List |
Class |
tactic.ui.table.WorkHoursElementWdg |
TACTIC Version Support |
2.5.0 + |
Required database columns |
none |
The Work Hours List Element is a common column that can be added to any task view using the Column Manager.