Overhauling ShotGrid Statuses With Webhooks

This blog post outlines a way to revamp ShotGrid statuses for production with a webhooks server and careful planning.

Statuses 2.0

"Versions affecting Tasks affecting Shots."

In order to redesign your status workflow in ShotGrid, the first thing to understand is that any entity in ShotGrid can have a status. Shots, Versions, Tasks, in ShotGrid these are considered "entities" meaning they can hold a number of attributes or "fields", one of which is a status.

When working in live action VFX, statuses are typically used for your Shots. You can get more granular if you've incorporated a task workflow, i.e for what specifically needs to be done on a shot, and more granular further, for versions, which can be iterations of work done for a task on that shot.

Excerpt from Intro to ShotGrid Schema

It's smart then, to look at the tree as Versions affecting Tasks affecting Shots. Moreover, each change needs to be communicated to the relevant party. For example, any time a version gets approved internally and the status flipped to "send to client", the task should be flipped as well, so that the artist knows their work is going over to the client. Continuing from that, if a task is set to "client approved" that information needs to go to a producer who might only be looking at shot information to get a top-line view of the project. This is broken down below:

Example

A version status change to "Check New Version"

A task status automatically changing to "Check New Version"

A version status change to "Client Approved"

Both task status and shot status change to "Client Approved"

A full example can be found here.

The configuration for your status mapping (details about what statuses you use at your specific shop, and how you'd like them to relate to eachother) can be found in the .yaml file in the below Git Repo.

🤖Here's the full repo for the webhooks service👾

Webhooks Firebase Application Documentation

Functions are hosted on firebase and endpoints can be reachable by setting up ShotGrid's webhooks workflow.

This repo is full of code ported from @sinclairtarget who did the original work for hosting on a windows machine on prem.

Firebase Docs: https://firebase.google.com/docs/cli

Features

• task_webhook: Handles ShotGrid Task status change events (i.e changing a shot status).
• version_webhook: Handles ShotGrid Version status change events (i.e changing a task status).
• version_created_webhook: Handles ShotGrid Version creation events (an extra step so new versions have a default status).
• Local Testing: A main function for testing via the Functions Framework.

Project Structure

functions/
├── config.json            # ShotGrid & secret token configuration
├── status_mapping.yaml    # Version statuses & task relations
├── requirements.txt       # Python dependencies
├── main.py                # Cloud Functions entrypoints & dispatch logic
├── .firebaserc            # Firebase project settings
├── .gitignore             # Ignored files
└── venv/                  # Python virtual environment

To make changes:

Please refer to firebase docs for info on first time firebase initialization.

Get to the right place:

cd functions

Create environment:

python -m venv .venv

Activate environment:

.venv/bin/activate

Grab those dependencies:

pip install -r requirements.txt

Deploy:

firebase deploy --only functions

Logs:

firebase functions:log

Configuration

1. Copy config.json and update values:

   {
     "SHOTGRID_API_KEY": "<your_api_key>",
     "SHOTGRID_SCRIPT_NAME": "<your_script_name>",
     "SECRET_TOKEN": "<your_secret_token>",
     "SHOTGRID_URL": "https://your.shotgrid.url"
   }

2. Adjust status_mapping.yaml to match your ShotGrid status keys and labels, and define any task-step relationships:

   version_statuses:
     - key: na
       label: N/A
     - key: stcomp
       label: Step Completed
     # ... more statuses
     task_step_relations:
     Rotoscoping:
       triggers_on_status: stcomp
       update_steps:
         - Composite
         - Secondary Composite
       new_status: bfr
     # ... more relations

Usage

Check endpoints based on Firebase configuration.

• task_webhook: Deployed URL /task_webhook receives task status change webhooks.
• version_webhook: Deployed URL /version_webhook receives version status change webhooks.
• version_created_webhook: Deployed URL /version_created_webhook receives new version creation webhooks.

Each endpoint verifies the SECRET_TOKEN header, parses the JSON payload, and dispatches logic to ShotGrid per status_mapping.yaml rules.

Deployment

1. Log in to Firebase:

   firebase login

2. Initialize Firebase (if not already done):

   firebase init functions

3. Deploy functions (Gen-2):

   firebase deploy --only functions