-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
prio: p3Low priority, backlogLow priority, backlogsize: mMedium, a few hours to a dayMedium, a few hours to a daystatus: needs infoRequires more information to proceedRequires more information to proceedtype: choreMaintenance, refactoring, dependenciesMaintenance, refactoring, dependencies
Description
Problem
The events table schema only stores a subset of the fields available from the Granola API. During sync, several fields from CalendarEvent are persisted, but others are silently dropped:
Stored: id, summary, start_time, end_time, calendar_id, attendees_json, conference_data_json, description, extra_json
Not stored: creator, organizer, recurring_event_id, ical_uid, status, html_link
When list_events() reconstructs CalendarEvent from the database, these fields are hardcoded to None (src/db/calendars.rs:87-93).
Investigation needed
- Are any of these fields useful for queries or display?
status(confirmed/tentative/cancelled) could be useful for filteringhtml_linkcould be displayed in meeting detail viewsrecurring_event_idcould help group recurring meetingsorganizer/creatorcould enrich people-related queries
- Should these be added via a migration, or are they low-value enough to leave in
extra_json? - The
extra_jsoncolumn with#[serde(flatten)]may already capture some of these if the API sends them as part of the response — worth verifying
Context
Noticed during #231 (type consolidation) — the consolidated CalendarEvent type has all these fields, but the DB layer can't round-trip them.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
prio: p3Low priority, backlogLow priority, backlogsize: mMedium, a few hours to a dayMedium, a few hours to a daystatus: needs infoRequires more information to proceedRequires more information to proceedtype: choreMaintenance, refactoring, dependenciesMaintenance, refactoring, dependencies