twotalesanimation
917 lines
12 KiB
Markdown
917 lines
12 KiB
Markdown
Update the existing FeedBack platform to add a lightweight production tracking system directly into the current architecture.
|
|
|
|
IMPORTANT:
|
|
Do NOT redesign the app from scratch.
|
|
Do NOT build enterprise production management.
|
|
Do NOT attempt full ShotGrid/ftrack complexity.
|
|
|
|
The goal is:
|
|
|
|
* simple
|
|
* fast
|
|
* usable
|
|
* production-focused
|
|
* minimal friction
|
|
|
|
FeedBack already has:
|
|
|
|
* projects
|
|
* shots
|
|
* versions
|
|
* reviews
|
|
* comments
|
|
* approvals
|
|
* client portal
|
|
|
|
We are now extending it into a lightweight VFX production tracker.
|
|
|
|
The philosophy should be:
|
|
“A clean operational layer for boutique VFX studios.”
|
|
|
|
---
|
|
|
|
# HIGH LEVEL GOAL
|
|
|
|
Add:
|
|
|
|
* production tracking
|
|
* tasks
|
|
* artist assignment
|
|
* deadlines
|
|
* kanban boards
|
|
* simple scheduling
|
|
* upload/review workflow integration
|
|
|
|
The existing review/version system should become directly attached to production tasks.
|
|
|
|
IMPORTANT:
|
|
The TASK should become the core production object.
|
|
|
|
Architecture should evolve toward:
|
|
|
|
```plaintext id="c2o8kh"
|
|
Project
|
|
├── Shots
|
|
│ ├── Tasks
|
|
│ │ ├── Versions
|
|
│ │ ├── Comments
|
|
│ │ └── Approvals
|
|
│
|
|
├── Assets
|
|
│ ├── Tasks
|
|
│ │ ├── Versions
|
|
│ │ ├── Comments
|
|
│ │ └── Approvals
|
|
```
|
|
|
|
---
|
|
|
|
# NEW CORE CONCEPTS
|
|
|
|
Add:
|
|
|
|
* Assets
|
|
* Tasks
|
|
* Artist Assignment
|
|
* Kanban Views
|
|
* Deadlines
|
|
* Task Statuses
|
|
|
|
DO NOT add:
|
|
|
|
* timesheets
|
|
* complex dependencies
|
|
* render management
|
|
* resource planning
|
|
* advanced scheduling
|
|
* Gantt charts
|
|
|
|
Keep the system intentionally lightweight.
|
|
|
|
---
|
|
|
|
# DATABASE CHANGES
|
|
|
|
## NEW ENUM: `TaskStatus`
|
|
|
|
Add:
|
|
|
|
```ts
|
|
TODO
|
|
IN_PROGRESS
|
|
REVIEW
|
|
CHANGES
|
|
DONE
|
|
```
|
|
|
|
---
|
|
|
|
## NEW ENUM: `TaskType`
|
|
|
|
Add:
|
|
|
|
```ts
|
|
TRACK
|
|
ROTO
|
|
KEY
|
|
COMP
|
|
FX
|
|
LIGHTING
|
|
RENDER
|
|
ANIMATION
|
|
MODEL
|
|
TEXTURE
|
|
RIG
|
|
LOOKDEV
|
|
GENERAL
|
|
```
|
|
|
|
Allow custom values later.
|
|
|
|
---
|
|
|
|
# NEW MODEL: `Asset`
|
|
|
|
Assets should behave similarly to shots.
|
|
|
|
Fields:
|
|
|
|
* id
|
|
* projectId
|
|
* assetCode
|
|
* name
|
|
* description
|
|
* status
|
|
* priority
|
|
* assignedLeadId
|
|
* dueDate
|
|
* createdAt
|
|
* updatedAt
|
|
|
|
Assets belong to:
|
|
|
|
* Project
|
|
|
|
Assets contain:
|
|
|
|
* Tasks
|
|
|
|
---
|
|
|
|
# NEW MODEL: `Task`
|
|
|
|
This becomes the core operational object.
|
|
|
|
Fields:
|
|
|
|
* id
|
|
* title
|
|
* description
|
|
* type
|
|
* status
|
|
* priority
|
|
* dueDate
|
|
* estimatedHours
|
|
* sortOrder
|
|
* shotId (nullable)
|
|
* assetId (nullable)
|
|
* assignedArtistId (nullable)
|
|
* createdById
|
|
* createdAt
|
|
* updatedAt
|
|
|
|
Rules:
|
|
|
|
* task belongs to either:
|
|
|
|
* a Shot
|
|
* or an Asset
|
|
* never both
|
|
|
|
Tasks can contain:
|
|
|
|
* Versions
|
|
* Comments
|
|
* Approvals
|
|
|
|
IMPORTANT:
|
|
Refactor existing Version model:
|
|
|
|
* versions should optionally belong to a Task
|
|
* NOT only a Shot
|
|
|
|
This is critical.
|
|
|
|
---
|
|
|
|
# VERSION REFACTOR
|
|
|
|
Currently:
|
|
|
|
```plaintext id="vw7z0h"
|
|
Shot -> Versions
|
|
```
|
|
|
|
Refactor to:
|
|
|
|
```plaintext id="7wfp9e"
|
|
Task -> Versions
|
|
```
|
|
|
|
Reason:
|
|
The review process is task-specific.
|
|
|
|
Example:
|
|
|
|
```plaintext id="x4fq6o"
|
|
SH010
|
|
├── Track Task
|
|
│ └── Versions
|
|
│
|
|
├── Roto Task
|
|
│ └── Versions
|
|
│
|
|
└── Comp Task
|
|
└── Versions
|
|
```
|
|
|
|
This massively improves production clarity.
|
|
|
|
Still allow:
|
|
|
|
* shot-level overview
|
|
* latest task version summary
|
|
|
|
---
|
|
|
|
# TASK WORKFLOW
|
|
|
|
Tasks should support:
|
|
|
|
* assignment
|
|
* deadlines
|
|
* uploads
|
|
* review
|
|
* approvals
|
|
|
|
Simple lifecycle:
|
|
|
|
```plaintext id="y8y95u"
|
|
TODO
|
|
→ IN_PROGRESS
|
|
→ REVIEW
|
|
→ CHANGES
|
|
→ DONE
|
|
```
|
|
|
|
---
|
|
|
|
# KANBAN BOARD
|
|
|
|
Implement lightweight kanban production views.
|
|
|
|
Views:
|
|
|
|
* By Project
|
|
* By Shot
|
|
* By Asset
|
|
* By Artist
|
|
|
|
Columns:
|
|
|
|
* Todo
|
|
* In Progress
|
|
* Review
|
|
* Changes
|
|
* Done
|
|
|
|
Cards should display:
|
|
|
|
* task title
|
|
* shot/asset code
|
|
* assigned artist
|
|
* due date
|
|
* latest version
|
|
* comment count
|
|
* approval state
|
|
|
|
Support:
|
|
|
|
* drag and drop
|
|
* optimistic updates
|
|
* instant status changes
|
|
|
|
Use:
|
|
|
|
* dnd-kit
|
|
|
|
NOT:
|
|
|
|
* giant enterprise scheduling systems
|
|
|
|
---
|
|
|
|
# NEW ROUTES
|
|
|
|
## Dashboard
|
|
|
|
Add:
|
|
|
|
```plaintext id="pwttmf"
|
|
/tasks
|
|
/tasks/[taskId]
|
|
```
|
|
|
|
---
|
|
|
|
## Project Views
|
|
|
|
Extend:
|
|
|
|
```plaintext id="6yq0o5"
|
|
/projects/[id]
|
|
```
|
|
|
|
Add tabs:
|
|
|
|
* Shots
|
|
* Assets
|
|
* Tasks
|
|
* Kanban
|
|
* Activity
|
|
|
|
---
|
|
|
|
## Asset Views
|
|
|
|
Add:
|
|
|
|
```plaintext id="y5xj4q"
|
|
/projects/[id]/assets/[assetId]
|
|
```
|
|
|
|
---
|
|
|
|
## Task Views
|
|
|
|
Add:
|
|
|
|
```plaintext id="g3fcdj"
|
|
/tasks/[taskId]
|
|
```
|
|
|
|
Task page should contain:
|
|
|
|
* task details
|
|
* status
|
|
* assignment
|
|
* uploads
|
|
* comments
|
|
* review player
|
|
* annotations
|
|
* approval history
|
|
|
|
Essentially:
|
|
task page = review page + production metadata
|
|
|
|
---
|
|
|
|
# REVIEW SYSTEM INTEGRATION
|
|
|
|
DO NOT duplicate review systems.
|
|
|
|
Existing:
|
|
|
|
* review player
|
|
* comments
|
|
* annotations
|
|
* approvals
|
|
|
|
should now attach to:
|
|
|
|
* Task Versions
|
|
|
|
The review player remains mostly unchanged.
|
|
|
|
---
|
|
|
|
# VERSION UPLOAD FLOW
|
|
|
|
New upload flow:
|
|
|
|
```plaintext id="v3r0xy"
|
|
Project
|
|
→ Shot / Asset
|
|
→ Task
|
|
→ Upload Version
|
|
```
|
|
|
|
Version uploads should:
|
|
|
|
* automatically increment version number
|
|
* optionally notify assigned reviewers
|
|
* optionally move task to REVIEW
|
|
|
|
---
|
|
|
|
# TASK CREATION UX
|
|
|
|
Allow:
|
|
|
|
* manual task creation
|
|
* templates
|
|
* quick-add buttons
|
|
|
|
Example:
|
|
For shots:
|
|
|
|
* Add Track
|
|
* Add Roto
|
|
* Add Comp
|
|
|
|
For assets:
|
|
|
|
* Add Model
|
|
* Add Texture
|
|
* Add Rig
|
|
|
|
---
|
|
|
|
# ARTIST ASSIGNMENTS
|
|
|
|
Tasks should support:
|
|
|
|
* assigned artist
|
|
* assigned supervisor
|
|
* watcher/follower users
|
|
|
|
Add lightweight workload views:
|
|
|
|
* my tasks
|
|
* due this week
|
|
* overdue
|
|
* awaiting review
|
|
|
|
---
|
|
|
|
# DASHBOARD IMPROVEMENTS
|
|
|
|
Add widgets:
|
|
|
|
* Tasks Due Today
|
|
* Tasks In Review
|
|
* Overdue Tasks
|
|
* Latest Uploads
|
|
* Recent Feedback
|
|
* Artist Workload
|
|
|
|
---
|
|
|
|
# NOTIFICATIONS
|
|
|
|
Extend notification system.
|
|
|
|
New notification types:
|
|
|
|
```ts
|
|
TASK_ASSIGNED
|
|
TASK_OVERDUE
|
|
TASK_APPROVED
|
|
TASK_CHANGES_REQUESTED
|
|
TASK_READY_FOR_REVIEW
|
|
```
|
|
|
|
Slack examples:
|
|
|
|
```plaintext id="hjlwmz"
|
|
SH010 COMP task ready for review
|
|
```
|
|
|
|
```plaintext id="64q9vx"
|
|
ASSET_CAR01 MODEL task approved
|
|
```
|
|
|
|
---
|
|
|
|
# PERMISSIONS
|
|
|
|
Maintain current auth architecture.
|
|
|
|
Permissions:
|
|
|
|
* ADMIN/PRODUCER/SUPERVISOR:
|
|
full task control
|
|
* ARTIST:
|
|
view assigned tasks
|
|
upload versions
|
|
comment
|
|
* CLIENT:
|
|
review approved review sessions only
|
|
|
|
Clients should NEVER see:
|
|
|
|
* kanban
|
|
* production internals
|
|
* task assignments
|
|
|
|
---
|
|
|
|
# UI REQUIREMENTS
|
|
|
|
The UI should feel:
|
|
|
|
* modern
|
|
* dark-mode first
|
|
* fast
|
|
* clean
|
|
* film-production oriented
|
|
|
|
Inspiration:
|
|
|
|
* Linear
|
|
* Trello
|
|
* Frame.io
|
|
* ShotGrid (but MUCH simpler)
|
|
|
|
---
|
|
|
|
# IMPORTANT PRODUCT DIRECTION
|
|
|
|
This should feel like:
|
|
“Trello + Frame.io specifically for boutique VFX studios.”
|
|
|
|
NOT:
|
|
“Enterprise production software.”
|
|
|
|
Keep:
|
|
|
|
* interactions fast
|
|
* layouts uncluttered
|
|
* onboarding minimal
|
|
|
|
---
|
|
---
|
|
|
|
# CLIENT REVIEW SHARING FLOW
|
|
|
|
Add a lightweight “Share With Client” workflow directly into the production/review system.
|
|
|
|
The goal is:
|
|
|
|
* one-click client sharing
|
|
* minimal friction
|
|
* no complicated publishing workflows
|
|
* tightly integrated into task review
|
|
|
|
This should feel extremely simple for producers/supervisors.
|
|
|
|
---
|
|
|
|
# CORE CONCEPT
|
|
|
|
A task version can move through two review stages:
|
|
|
|
```plaintext id="y5ibk0"
|
|
Internal Review
|
|
→ Client Review
|
|
→ Approved / Changes
|
|
```
|
|
|
|
When a user clicks:
|
|
|
|
```plaintext id="l5l90p"
|
|
Share With Client
|
|
```
|
|
|
|
the system should:
|
|
|
|
* mark the task/version as ready for client review
|
|
* expose the version in the client portal
|
|
* optionally notify the client
|
|
* generate/share a review link if needed
|
|
|
|
IMPORTANT:
|
|
Do NOT require duplicate uploads or separate publish steps.
|
|
|
|
The uploaded task version itself becomes the client review version.
|
|
|
|
---
|
|
|
|
# NEW TASK STATUS
|
|
|
|
Extend `TaskStatus` enum:
|
|
|
|
```ts id="z1vc6r"
|
|
TODO
|
|
IN_PROGRESS
|
|
INTERNAL_REVIEW
|
|
CLIENT_REVIEW
|
|
CHANGES
|
|
DONE
|
|
```
|
|
|
|
This mirrors actual VFX review flow more accurately.
|
|
|
|
---
|
|
|
|
# SHARE WITH CLIENT BUTTON
|
|
|
|
Add a prominent:
|
|
|
|
```plaintext id="mqkn6v"
|
|
Share With Client
|
|
```
|
|
|
|
button in multiple locations.
|
|
|
|
## PRIMARY LOCATION
|
|
|
|
Inside the internal review player page:
|
|
|
|
```plaintext id="m1sjc9"
|
|
/review/[versionId]
|
|
```
|
|
|
|
This is the most important placement.
|
|
|
|
Supervisors reviewing a version internally should be able to immediately push it to client review.
|
|
|
|
---
|
|
|
|
## ADDITIONAL LOCATIONS
|
|
|
|
Add button/action in:
|
|
|
|
* task detail page
|
|
* version list rows
|
|
* kanban task cards
|
|
* project shot overview
|
|
* latest version cards
|
|
|
|
Use:
|
|
|
|
* dropdown action menu
|
|
* quick action button
|
|
* contextual right-click menu where appropriate
|
|
|
|
---
|
|
|
|
# SHARE FLOW
|
|
|
|
When clicked:
|
|
|
|
## IF NO ACTIVE CLIENT REVIEW SESSION EXISTS
|
|
|
|
Prompt:
|
|
|
|
```plaintext id="4v0j9h"
|
|
Create review link for client?
|
|
```
|
|
|
|
Allow:
|
|
|
|
* create new tokenized review session
|
|
* select existing review session
|
|
* choose expiry date
|
|
* optional password later
|
|
* optional email send
|
|
|
|
---
|
|
|
|
## IF REVIEW SESSION EXISTS
|
|
|
|
Immediately:
|
|
|
|
* mark version as client-visible
|
|
* move task to CLIENT_REVIEW
|
|
* notify client if enabled
|
|
|
|
---
|
|
|
|
# VERSION VISIBILITY
|
|
|
|
Add fields to `Version`:
|
|
|
|
```ts id="e88z4o"
|
|
isClientVisible Boolean @default(false)
|
|
sharedAt DateTime?
|
|
sharedById String?
|
|
```
|
|
|
|
Only versions with:
|
|
|
|
```plaintext id="vlfvhy"
|
|
isClientVisible = true
|
|
```
|
|
|
|
appear in client portal APIs.
|
|
|
|
This is MUCH cleaner than relying only on shot status.
|
|
|
|
---
|
|
|
|
# CLIENT REVIEW RULES
|
|
|
|
Clients should ONLY see:
|
|
|
|
* explicitly shared versions
|
|
* latest shared version by default
|
|
|
|
Clients should NEVER see:
|
|
|
|
* internal versions
|
|
* WIP uploads
|
|
* rejected internal passes
|
|
* production notes
|
|
* kanban/task internals
|
|
|
|
---
|
|
|
|
# CLIENT REVIEW UX
|
|
|
|
When shared:
|
|
|
|
* client sees version immediately in portal
|
|
* can comment
|
|
* approve
|
|
* request changes
|
|
|
|
Client actions should:
|
|
|
|
* update task status automatically
|
|
* create notifications
|
|
* appear in activity feed
|
|
|
|
Example:
|
|
|
|
```plaintext id="yv2hfe"
|
|
Client approved SH010 COMP v004
|
|
```
|
|
|
|
Or:
|
|
|
|
```plaintext id="z61rq5"
|
|
Client requested changes on SH020 TRACK v002
|
|
```
|
|
|
|
---
|
|
|
|
# OPTIONAL EMAIL FLOW
|
|
|
|
Allow optional:
|
|
|
|
```plaintext id="jk3o5i"
|
|
Send Review Email
|
|
```
|
|
|
|
Email contains:
|
|
|
|
* project name
|
|
* shot/task name
|
|
* review link
|
|
* optional message
|
|
|
|
---
|
|
|
|
# SMART STATUS AUTOMATION
|
|
|
|
Recommended automatic transitions:
|
|
|
|
```plaintext id="mxti1g"
|
|
Upload Version
|
|
→ INTERNAL_REVIEW
|
|
|
|
Click "Share With Client"
|
|
→ CLIENT_REVIEW
|
|
|
|
Client Approves
|
|
→ DONE
|
|
|
|
Client Requests Changes
|
|
→ CHANGES
|
|
```
|
|
|
|
This keeps production flow extremely simple.
|
|
|
|
---
|
|
|
|
# UI REQUIREMENTS
|
|
|
|
The "Share With Client" action should feel:
|
|
|
|
* fast
|
|
* obvious
|
|
* production-friendly
|
|
|
|
Suggested styling:
|
|
|
|
* accent button
|
|
* paper-plane/share icon
|
|
* visible near approval controls
|
|
|
|
Avoid:
|
|
|
|
* buried menus
|
|
* multi-step publish systems
|
|
* complicated permission dialogs
|
|
|
|
---
|
|
|
|
# IMPORTANT PRODUCT DIRECTION
|
|
|
|
This feature is one of the biggest differentiators of the platform.
|
|
|
|
The ideal workflow should feel like:
|
|
|
|
```plaintext id="v5z9eo"
|
|
Artist uploads →
|
|
Supervisor reviews →
|
|
Clicks "Share With Client" →
|
|
Client reviews instantly
|
|
```
|
|
|
|
No exporting.
|
|
No re-uploading.
|
|
No external tools.
|
|
No confusion.
|
|
|
|
That simplicity is the product advantage.
|
|
|
|
---
|
|
|
|
# IMPLEMENTATION PLAN
|
|
|
|
Implement in phases.
|
|
|
|
## PHASE 1 — DATABASE & CORE MODELS
|
|
|
|
1. Add Asset model
|
|
2. Add Task model
|
|
3. Add Task enums
|
|
4. Refactor Version relationships
|
|
5. Add Prisma migrations
|
|
6. Seed example tasks/assets
|
|
|
|
---
|
|
|
|
## PHASE 2 — TASK CRUD
|
|
|
|
1. Task creation dialogs
|
|
2. Task detail page
|
|
3. Task assignment
|
|
4. Status updates
|
|
5. Due dates
|
|
6. Quick-add task templates
|
|
|
|
---
|
|
|
|
## PHASE 3 — VERSION INTEGRATION
|
|
|
|
1. Attach uploads to tasks
|
|
2. Refactor review routes
|
|
3. Task-based version history
|
|
4. Latest version indicators
|
|
|
|
---
|
|
|
|
## PHASE 4 — KANBAN
|
|
|
|
1. Build kanban board
|
|
2. Drag/drop task movement
|
|
3. Real-time updates
|
|
4. Artist filtering
|
|
5. Project filtering
|
|
|
|
---
|
|
|
|
## PHASE 5 — DASHBOARD & NOTIFICATIONS
|
|
|
|
1. Task widgets
|
|
2. Workload summaries
|
|
3. Slack updates
|
|
4. In-app notifications
|
|
5. Overdue indicators
|
|
6. Client Review button implementation
|
|
|
|
---
|
|
|
|
# IMPORTANT TECHNICAL REQUIREMENTS
|
|
|
|
Maintain:
|
|
|
|
* current auth system
|
|
* current storage abstraction
|
|
* current review functionality
|
|
* current client portal
|
|
|
|
Avoid:
|
|
|
|
* breaking existing APIs
|
|
* rewriting review logic
|
|
* giant refactors
|
|
|
|
This should be an additive evolution of the existing FeedBack architecture.
|
|
|
|
---
|
|
|