Event Planning Data Models

Overview

The event planning system uses a flexible, block-based architecture that allows for multiple planning scenarios, polymorphic associations, and extensive customization.

Implementation Status

✅ Implemented Models

• Event (with recurring event support)
• EventPlan
• EventBlock
• EventTask & EventTaskAssignee
• EventBudgetItem (amount stored as string for decimal precision)
• EventCollaborator
• EventPermission (using strings for wildcard support)
• EventPersonnel

⏳ Not Yet Implemented

• Vendor & EventBlockVendor
• Address (polymorphic)
• EventGuestList
• EventComment (stub exists, needs full implementation)

Core Architecture Patterns

• Polymorphic Associations: Budget items, addresses, and block containers use polymorphic patterns for maximum flexibility
• Integer Enums: All status/state fields use integers mapped to enums in code for easy display value updates
• Rich Text Fields: Descriptions support rich text formatting for enhanced user experience
• Extensible Metadata: JSONB fields provide flexibility for future feature additions

Entity Schemas

Core Event Tables

Event

EventPlan

Block & Task Tables

EventBlock (Polymorphic Container)

Block Container Logic:

• Draft blocks: blockable_type = 'Event' (belongs to event directly)
• Plan blocks: blockable_type = 'EventPlan' (belongs to specific plan)
• Future extensibility: Could support multiple draft areas per user/plan

EventTask & Assignments

Vendor Tables

Vendor & Block Associations

Polymorphic Support Tables

Address (Polymorphic)

EventBudgetItem (Polymorphic)

Collaboration & Access Management

EventCollaborator

EventPermission (Zanzibar-style)

EventPersonnel

EventComment (Polymorphic + Nested)

EventGuestList

Reference Tables

User & Organization

Entity Relationships

Key Business Rules

Event & Organization Ownership

• Event ownership: Events belong to organizations, not individual users
• Collaborator access: Organization members can be added as EventCollaborators
• Personnel decoupling: EventPersonnel are text entries, not linked to Member records for contact preservation

Polymorphic Associations

• Block containers: Draft blocks (blockable_type = 'Event') vs plan blocks (blockable_type = 'EventPlan')
• Budget items: Can attach to plans, blocks, tasks, or vendor associations via polymorphic budgetable_* fields
• Addresses: Polymorphic addressable_* fields support Events, Vendors, and EventPersonnel
• Comments: Polymorphic commentable_* fields support blocks and tasks with nested threading via parent_id

Task Assignment

• Multi-assignee support: Through EventTaskAssignee join table
• Organization scope: Tasks assigned to organization members via member_id references

Vendor Categories

• Platform vendors: Shared across organizations (organization_id = NULL)
• Organization vendors: Private to specific organizations
• External vendors: Populated from search APIs (Google Places, etc.)

Permission Model

• Zanzibar-style: Subject-action-resource tuples in EventPermission table
• Permission inheritance: Higher-level permissions cascade down the hierarchy

Implementation Notes

Database Indexes

Key indexes needed for performance:

• EventBlock(blockable_type, blockable_id) - Polymorphic lookups
• EventBudgetItem(budgetable_type, budgetable_id) - Budget aggregations
• EventTaskAssignee(member_id) - Member task queries
• EventComment(commentable_type, commentable_id) - Comment threads
• EventCollaborator(event_id, member_id) - Unique collaborator lookups
• EventPermission(subject_type, subject_id, resource_type, resource_id) - Permission checks
• EventPersonnel(event_id) - Event staff queries

Migration Strategy

1. Create core tables (Event, EventPlan, EventBlock, EventTask)
2. Add access management (EventCollaborator, EventPermission, EventPersonnel)
3. Add polymorphic support tables (Address, EventBudgetItem)
4. Create collaboration tables (EventComment, EventTaskAssignee)
5. Add vendor integration (Vendor, EventBlockVendor)
6. Add guest management (EventGuestList)

Future Considerations

• Multiple draft areas: Polymorphic design supports this naturally
• B2B features: Event-specific naming allows for separate B2B models
• Advanced permissions: Foundation ready for granular access control
• Real-time collaboration: Schema supports activity tracking and notifications

---

For authentication models (User, Organization), see Authentication Data Models

For actual migration files, see apps/server/database/migrations/