Objective
Give office staff an auditable trail for calendar time blocks and related events (who, when, what changed), and make system-generated calendar entries easy to distinguish from manual blocks so dispatchers can troubleshoot automation versus human edits.
Background
- Scheduling disputes today require Slack threads or guesswork because calendar mutations do not expose actor metadata in one place.
- Calendar data persists through backend event models such as
attik-backend/src/models/eventSchema.tsand recurring helpers inattik-backend/src/models/reoccuringCalendarEventSchema.ts, while dispatch consumes summaries throughattik-frontend/src/app/tools/dispatch/DispatchCalendar.tsxandattik-frontend/src/components/calendar/CalendarBase.tsx. - Work order history already centralizes many mutations inside
attik-frontend/src/components/activityFeed/ActivityFeed.tsx, which may be a natural surface for cross-linking calendar audit entries once data exists.
Scope
Backend
- Decide what metadata must be stored on create, update, and delete for both manual blocks and service-driven events so the UI can filter and label them.
Frontend
- Surface the audit trail in the calendar UI, the activity feed, or both. Layout and navigation patterns are left to the implementer.
References
attik-backend/src/models/eventSchema.tsattik-backend/src/models/reoccuringCalendarEventSchema.tsattik-frontend/src/components/activityFeed/ActivityFeed.tsxattik-frontend/src/app/tools/dispatch/DispatchCalendar.tsx
