Case Update Data Model Analysis

Current State Comparison

Seeding Script vs API Route vs Documentation

Field	Seeding Script	API Route	Documentation	Status
id	✅ Required	✅ Required	✅ Required	✅ Match
caseId	✅ Required	✅ Required	✅ Required	✅ Match
type	✅ Required	✅ Required	✅ Required	✅ Match
status	✅ Optional	✅ Optional	✅ Optional	✅ Match
previousStatus	✅ Optional	✅ Optional	✅ Optional	✅ Match
notes	✅ Optional	✅ Optional	✅ Optional	✅ Match
updatedBy	✅ Required	✅ Required	✅ Required	⚠️ VALUE ISSUE
updatedByName	✅ Required	✅ Required	✅ Required	⚠️ VALUE ISSUE
createdAt	✅ Required (string)	✅ Required (string)	✅ Required (Date)	⚠️ TYPE MISMATCH
updatedAt	❌ Missing	❌ Missing	❌ Missing	❌ MISSING
metadata	✅ Optional	✅ Optional	✅ Optional	✅ Match
metadata.attachmentUrl	✅ Optional	✅ Optional	✅ Optional	✅ Match
metadata.tags	✅ Optional	✅ Optional	✅ Optional	✅ Match
metadata.priority	✅ Optional	✅ Optional	✅ Optional	✅ Match

Issues Identified

1. Missing updatedAt Field

• Seeding: No updatedAt field
• API Route: No updatedAt field
• Documentation: No updatedAt field
• Impact: No tracking of when updates are modified
• Recommendation: Add updatedAt field (set to createdAt on creation, updated on modification)

2. updatedBy and updatedByName Hardcoded in API

• API Route: Hardcoded to 'system' and 'System User' (TODO comments)
• Seeding: Properly uses actual user IDs and names
• Impact: All updates created via API show as "System User"
• Recommendation: Implement proper Firebase Auth to get actual user info

3. Type Mismatch: createdAt

• Documentation: Says Date type
• Seeding/API: Uses string (ISO 8601)
• Impact: Documentation inconsistency
• Recommendation: Standardize on string (ISO 8601) to match Firestore

4. Denormalized updatedByName

• Current: Stores both updatedBy (ID) and updatedByName (denormalized)
• Question: Should we keep denormalized name or fetch from users collection?
• Recommendation: Keep denormalized for performance (display name needed frequently)

5. Status Field Type

• Current: status?: string (free-form)
• Documentation: status?: CaseStatus (typed)
• Seeding: Uses string values like 'draft', 'active', 'completed'
• Question: Should status be typed or free-form?
• Recommendation: Use typed CaseStatus for consistency with Case model

6. Metadata Structure

• Current: Flexible object with optional fields
• Question: Should metadata be more structured or stay flexible?
• Recommendation: Keep flexible for extensibility, but document common fields

Recommendations

1. Add updatedAt Field

Recommendation: Add updatedAt to track modifications

createdAt: string;  // ISO 8601
updatedAt: string;  // ISO 8601, set to createdAt on creation

2. Fix API Authentication

Recommendation: Implement Firebase Auth in API route

• Get updatedBy from authenticated user
• Fetch updatedByName from users collection or include in token

3. Standardize Timestamp Type

Recommendation: Use string (ISO 8601) consistently

• Update documentation to say string not Date
• Matches Firestore storage format

4. Type Status Field

Recommendation: Use CaseStatus type for status field

status?: CaseStatus;  // 'draft' | 'active' | 'urgent' | 'completed'

5. Keep Denormalized Name

Recommendation: Keep updatedByName for performance

• Needed for display without extra queries
• Update when user changes name (optional, not critical)

Questions for User

1. Status Type: Should status be typed (CaseStatus) or free-form string?

   • My recommendation: Typed for consistency

2. UpdatedAt: Should we add updatedAt field?

   • My recommendation: Yes, for tracking modifications

3. Denormalized Name: Keep updatedByName or fetch from users collection?

   • My recommendation: Keep denormalized for performance

4. Metadata Structure: Keep flexible or make more structured?

   • My recommendation: Keep flexible but document common fields

5. Update Types: Are all 4 types (status_change, note, comment, milestone) actually used?

   • My recommendation: Verify usage, remove if not needed

6. API Auth: Should we implement Firebase Auth in API route now or later?

   • My recommendation: Document as TODO, implement later