LinkDesk/openspec/changes/add-shot-data-table-column-display-switch-to-sidebar/design.md

Context

The VFX Studio application currently has a ShotColumnVisibilityControl component in the Shot page toolbar that allows users to toggle which columns to display in the Shot data table. However, this control is only accessible when users are on the Shot page. Users have requested the ability to quickly toggle Shot table columns from the Sidebar so they can adjust column visibility without navigating to the Shot page first.

This change will add a column display switch to the application Sidebar, making column visibility controls accessible from anywhere in the application.

Goals / Non-Goals

Goals:

• Add a column visibility control to the AppSidebar component
• Create a global column visibility state accessible throughout the application
• Ensure column preferences persist across user sessions using localStorage
• Maintain consistency with the existing ShotColumnVisibilityControl component

Non-Goals:

• Backend API changes (not required)
• Database schema changes (not required)
• Modifying the existing Shot page column visibility functionality
• Adding column visibility controls for other data tables (e.g., Tasks, Assets)

Decisions

1. Global State Management Approach

Decision: Use a Pinia store for global column visibility state with localStorage persistence.

Rationale:

• Pinia is already the state management solution used in the project
• localStorage provides simple persistence without backend changes
• This approach aligns with existing patterns in the codebase

Alternative Considered: Use Vue's provide/inject pattern

• Rejected because it doesn't provide automatic persistence and is less scalable

2. Sidebar Integration Location

Decision: Add the column display switch as a new SidebarGroup in the AppSidebar component, positioned in the SidebarContent area.

Rationale:

• Keeps the control accessible but not obtrusive
• Follows the existing Sidebar organization pattern (Navigation, Administration, Developer Tools)
• Allows for future expansion to other column visibility controls

Alternative Considered: Add to SidebarFooter

• Rejected because Footer is already used for UserMenu and would become cluttered

3. Reuse Existing Component vs. New Implementation

Decision: Create a new Sidebar-specific component that adapts the existing ShotColumnVisibilityControl logic.

Rationale:

• The existing ShotColumnVisibilityControl is tightly coupled to the Shot page context
• A sidebar-specific component can be simpler and more focused
• Allows for different UI presentation in sidebarmore compact)

** context (Alternative Considered:** Reuse ShotColumnVisibilityControl directly

• Rejected because it has Shot-specific UI elements (toolbar styling, select dropdown)

4. Default Column Visibility

Decision: Default visibility: Thumbnail, Shot Name, Episode, Status visible; all task type columns hidden.

Rationale:

• Matches typical VFX production workflow priorities
• Reduces visual clutter for new users
• Aligns with the current Shot page defaults

Risks / Trade-offs

[Risk] State synchronization between Sidebar control and Shot page control → Mitigation: Both controls will read from and write to the same Pinia store, ensuring consistency

[Risk] Performance impact from reactive column visibility state → Mitigation: Column visibility is a simple object; Vue's reactivity system handles this efficiently

[Risk] User confusion if Sidebar is collapsed → Mitigation: The column control will be hidden when sidebar is collapsed (consistent with other sidebar content)

Migration Plan

1. Create new Pinia store for column visibility (e.g., useColumnVisibilityStore)
2. Create new SidebarColumnSwitch component
3. Add SidebarColumnSwitch to AppSidebar.vue
4. Update ShotColumnVisibilityControl to use the new store
5. Test state synchronization between Sidebar and Shot page
6. No rollback needed - this is a purely additive feature

Open Questions

1. Should the column visibility settings be per-project or global across all projects?

   • Current design assumes global (simpler implementation)
   • Could be enhanced later if users request per-project settings

2. Should we show all task type columns or only a subset in the Sidebar?

   • Current design shows all available task types
   • Could be limited to top 5 most-used types if the list becomes too long