To allow for separate versioning of files within the same SObject (container) during checkin, TACTIC uses "versions" and "contexts." Snapshot data always includes this information.
Contexts define a separate "channel" for checking in files. For example, one SObject may require separate files to be checked in for different tasks. For example, in the following list one drawing file is checked into a single SObject with both "rough" and "final" contexts (and with multiple versions). In this case, the contexts represent files checked in for both the rough and final processes (tasks).
/assets/myProject/drawings/drawing_001/drawing_001_rough_v001.png /assets/myProject/drawings/drawing_001/drawing_001_rough_v002.png /assets/myProject/drawings/drawing_001/drawing_001_rough_v003.png /assets/myProject/drawings/drawing_001/drawing_001_final_v001.png /assets/myProject/drawings/drawing_001/drawing_001_final_v002.png
SObjects in TACTIC are not actual physical files, but instead they are descriptive containers that store all the information necessary to define an object and track it. If the definition of the Search Type permits, an SObject can contain relationships to child SObjects. Separate SObject children can be used to store extra data. For example, they could be "task" SObjects set up based on the pipeline to track approvals and notes, or they could be "snapshot" SObjects that store file checkin and location information.
In a project, an SObject can be used to store the production data for any digital asset requiring multiple associated files. When you create a new SObject, you must create it based on a Search Type (for example, the "model" Search Type). When you insert this new SObject, you are simply inserting a new entry into the "model" Search Type’s library. Based on the associated template Search Type, the new SObject will require specific data to be inserted. For example, a name, description, pipeline code and so on.
At times you may wish to offline an Search Object but, not remove it from the system. Every search type has a s_status preperty that when set to retired hides the SObject but, makes is easy to reactivate it.
Views provide users with what they need to see and how they need to see it. The are collections of different Search Type properties which are relevant to a team members role in Tactic. Views are mainly accessed through links in the sidebar either as Project Views which are configured for the whole production (but ca be controlled with access rules) and My Views which are views a uses saves as their own personal views or "bookmarks". Views can also contain a saved search which, provides a view as a live report.
Pipelines define a hierarchical set of processes that lay out all of the production and approval steps an SObject must go through before being completed. It is important to note that each process contains its own set of approvals (task pipeline). Typically a process must be completed before it can be handed off to the downstream process or processes. TACTIC uses pipelines in this manner: when a process is approved, the next downstream processes receive the green light to start.
When files are checked in to TACTIC, they are passed through the directory and file naming conventions. This relieves the user of the responsibility of figuring out where to place files on the server and what to name them. Naming conventions are defined using the "naming" Search Type, which stores an expression used by TACTIC to generate the location and name for a file upon checkin.
A query into TACTIC is a request to retrieve Search Objects from the database. In the Tactic interface when a user searches for something, they are doing a query.
Views in the TACTIC interface are built using a "Table" widget that is defined based on a Search Type. Views can be configured to display specific properties (columns) and also the widgets (tools) that are used to display them.
Views can also be filtered to control which SObjects are displayed with search tools. For example, search tools can create reports, or views summarizing which SObjects are at which stages in the pipeline. Views and reports can be saved as either project views, visible to multiple team members, or as personal views, visible to individuals ("My Views").
The TACTIC system is based on events, and every interaction with any SObject is tracked. Events may include changing a status, adding a note or checking in a file (to list but a few examples). Every event is logged into a transaction log, and can be undone. The transaction log is very valuable because it enables easy tracking of when something happened and who did it.
An event can also execute another event in the system (or a "trigger"). Triggers are set up as custom scripts which can be configured to do almost anything in TACTIC through the TACTIC Client API. Example uses of triggers include changing the status of another task SObject, checking in additional files, or executing an external rendering application.
When configuring TACTIC, it is important for both security and simplicity to set up appropriate access rules. Access Rules are typically applied to user groups, making it easier to control what different groups of users or departments can access in TACTIC.
A TACTIC project defines a real-world project or separates one of its timelines. Each TACTIC project has its own separate database and structure. Projects are the highest level separation in TACTIC. They represent a separation in workflow, Searchable Types, Views, Access Rules, Naming Conventions Pipelines and more
Custom TACTIC projects can be built from the ground up to manage specific types of objects, processes and files. Alternatively, predefined, ready-to-use TACTIC project modules are available to expedite the setup process and provide custom integration tools appropriate for the project type.
When you update an existing Serch Object in Tactic, this is called an update. For example if you change the description property (column entry), saving the cnages commits an update to the database.
A snapshot describes an asset at a particular point in time. This description is sufficient to reproduce the asset completely at that point in time. TACTIC has its own XML description language to completely define assets and their dependencies to other assets.
A snapshot can contain any number of files. For example, in a Flash production, a typical checkin will result in 4 files: a .fla (the flash file to work on), .swf (a viewable file), and 2 pngs which represent a small icon and a large viewable image.
Every time something is checked in, a new snapshot is created of the asset. Snapshots can reference other snapshots, which allows TACTIC to define dependencies to other assets or other snapshots of the same asset.
Within a project, there are many types of objects to manage, and each object type requires different properties and types of files to be stored. TACTIC uses Search Types to categorize the many types of objects that can exist in a project. Search Types are templates that determine how these objects are defined and handled. Views, pipelines, naming conventions, access rules (and more) are all defined based on assignment to a Search Type.
The basic architecture of the TACTIC system is built around interaction with objects through their Search Types. These objects or "instances of a Search Type" are called Search Objects or SObjects. The TACTIC interface is simply a layer of widgets (tools) delivered through a web browser that are provided for the user to search for SObjects, display them, and interact with them based on their Search Types.
Deleting a Search Object revoves it from the database completely. Although undoable, this is only right after doign so. If you are unsure, retiring is ofter a good choice.
A task is any job that occurs within a process, and is the fundamental atomic work element in project management. For details on tasks, go to Working with Tasks.
Notifications are triggers built to execute on specific configured events, and can be internal to TACTIC (notification SObjects), or even emails sent externally. Notifications can be configured to run based on rules that define the conditions that must be met in order to send out a message. Conditions help to streamline who receives a notification for a particular event, as well as the conditions specific to the event.
Triggers are specific tools and scripts that are executed based on events which occur in Tactic. Within the project setup, there are tools which help setup triggers and notifications with simple tools. Although if required, these Triggers can be quite complex. Using the TACTIC Client API, you can achieve almost anything. For example, a trigger can be called when a task’s status is changed. This type of trigger would first check what the status was changed to, and then only proceed to carry out a set of tasks if the status was, for example, "approved". This may be as simple as changing the status of another task or as complex as loading the final checkin for that task, render it to a video file and then check it back into TACTIC.
Checkouts in Tactic is when a user requests a particular snapshot. This request from the users standpoint can simply be a request for the current material which prompts TACTIC to deliver all of the files as well as any other dependant files to the user.
There are 2 ways for a user to actually retrieve the files for a snapshot.
Searchable Type metadata may also include a "pipeline_code" property to link the SObject to a pipeline SObject. In this event, task SObjects are also created from the pipeline’s processes to define the processes the SObject will pass through as it progresses through its production. When tasks (processes) are defined, they ensure that an asset can only move along the pipeline with all checkpoints complete. For example, they can determine that the assigned user checks in files, generates notes, sets task status and receives management approvals. After all of the associated tasks for the SObject are approved and it is packaged up and marked complete, its production history information, files, and data are all still available as a package.
A process is a definable phase in the pipeline of an asset. Processes require some type of delivery upon completion, and often require that an asset be checked in as part of the delivery mechanism. A process is typically assigned to one person or one department. For large projects, a single department could be assigned many processes.
The project schema defines the hierarchy between Search Types in TACTIC. The schema definitions are stored in a "schema" SObject which stores the parent and child relationships between the various Search Types in the project. The schema is automatically updated when search_types are created in TACTIC, and can be modified in a schema view.
Searchable Types define how you want to manage your objects and also define a separation in pipelines, views, checkin methods and more. They are some of the most important configuration aspects of TACTIC. The majority of the TACTIC architecture is built around the use of search types for the needs of the project as well as many of the system level aspects.
When creating new Search Objects in your project, you are effectiavely inserting a new row into the database. If you insert a new Art sObject, you are creating a new entry in the "art" table in your project’s database.
Checkins in Tactic is generally the process of placing and registering all of the files that represent a "snapshot" of that object. This snapshot is a package in itself that understands all of the versioning and location for all files and/or folders that are a part of that checkin.
With the notion of each Search Object being a container, creating snapshots can be compared to creating and storing packages in this container.
From the back-end of Tactic the great aspect of this process is that this package is simply meta data that points to where the actual files and folders live in the file system. The main benefits of this that if Tactic we to be shut off, the files system will still be available and very well organized.