- Backend now updates RRULE when recurrence_count or recurrence_end_date parameters are provided
- Fixed update_entire_series() to modify COUNT/UNTIL instead of preserving original RRULE
- Added comprehensive RRULE parsing functions to extract existing frequency, interval, count, until, and BYDAY components
- Fixed frontend parameter mapping to pass recurrence parameters through update_series calls
- Resolves issue where changing recurring event from 5 to 7 occurrences kept original COUNT=5
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Events were appearing 4 hours earlier than selected time due to incorrect
timezone handling in backend. The issue was treating frontend local time
as if it was already in UTC.
- Fix parse_event_datetime() in events.rs to properly convert local time to UTC
- Fix all datetime conversions in series.rs to use Local timezone conversion
- Replace Utc.from_utc_datetime() with proper Local.from_local_datetime()
- Add timezone conversion using with_timezone(&Utc) for accurate UTC storage
Now when user selects 5:00 AM, it correctly stores as UTC equivalent
and displays back at 5:00 AM local time.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Set all_day flag properly when creating VEvent in series handler
- Improve all-day event detection using VALUE=DATE parameter
- Add RFC-5545 compliance for exclusive end dates (backend adds 1 day)
- Fix end date display in event modal (frontend subtracts 1 day for display)
- Fix recurring all-day event expansion to maintain proper end date pattern
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Moved event fetching logic from CalendarView to Calendar component to properly
use the visible date range instead of hardcoded current month. The Calendar
component already tracks the current visible date through navigation, so events
now load correctly for August and other months when navigating.
Changes:
- Calendar component now manages its own events state and fetching
- Event fetching responds to current_date changes from navigation
- CalendarView simplified to just render Calendar component
- Fixed cargo fmt/clippy formatting across codebase
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Removed unused functions and variables identified after RRULE parameter fix:
- Remove unused build_series_rrule function from backend series handler
- Remove unused RecurrenceType::from_rrule and helper functions from frontend
- Prefix unused state variables with underscores to suppress warnings
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Clean up extensive console logging that was added during RRULE debugging.
Removed debug logs from:
- Frontend RRULE generation in create event modal
- Frontend RRULE parsing in calendar service
- Weekly/monthly/yearly occurrence generation functions
- Backend RRULE processing in events and series handlers
The core functionality remains unchanged - this is purely a cleanup
of temporary debugging output that is no longer needed.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit fixes a critical bug where INTERVAL and COUNT parameters
were being stripped from recurring events during backend processing.
Frontend was correctly generating complete RRULE strings like:
FREQ=WEEKLY;INTERVAL=2;BYDAY=TU,FR;COUNT=6
But backend was ignoring the complete RRULE and rebuilding from scratch,
resulting in simplified RRULEs like:
FREQ=WEEKLY;BYDAY=TU,FR (missing INTERVAL and COUNT)
Changes:
- Modified both events and series handlers to detect complete RRULE strings
- Added logic to use frontend RRULE directly when it starts with "FREQ="
- Maintained backwards compatibility with simple recurrence types
- Added comprehensive debug logging for RRULE generation
- Fixed weekly BYDAY occurrence counting to respect COUNT parameter
- Enhanced frontend RRULE generation with detailed logging
This ensures all RFC 5545 RRULE parameters are preserved from
frontend creation through CalDAV storage and retrieval.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Aligns update_entire_series with the same metadata preservation approach
used in this_only and this_and_future update methods.
## Key Changes:
1. **Clone-and-Modify Pattern**:
- Clone existing event to preserve all metadata (organizer, attendees, etc.)
- Only modify specific properties that need to change
- Maintains consistency with other update methods
2. **Smart Field Handling**:
- Preserve original values when request fields are empty
- Only overwrite when new values are explicitly provided
- Same selective update logic as other scopes
3. **RRULE Preservation**:
- Keep existing recurrence pattern unchanged for simple updates
- Suitable for drag operations that just change start/end times
- Avoids breaking complex RRULE patterns unnecessarily
4. **Proper Timestamp Management**:
- Update dtstamp and last_modified to current time
- Preserve original created timestamp for event history
- Consistent timestamp handling across all update types
## Benefits:
- All three update scopes now follow the same metadata preservation pattern
- Simple time changes (drag operations) work without side effects
- Complex event properties maintained across all modification types
- Better RFC 5545 compliance through proper event structure preservation
## Removed:
- Complex RRULE regeneration logic (build_series_rrule function now unused)
- Manual field-by-field assignment replaced with selective clone modification
This ensures consistent behavior whether users modify single occurrences,
future events, or entire series - all maintain original event metadata.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Resolves multiple issues with single occurrence modification to implement
correct CalDAV/RFC 5545 exception patterns:
## Key Fixes:
1. **Eliminate Double Updates**:
- Removed redundant client.update_event() call from update_single_occurrence
- Main handler now performs single CalDAV update, preventing conflicts
2. **Preserve Event Metadata**:
- Changed from creating new event to cloning existing event
- Maintains organizer, attendees, categories, and all original properties
- Only modifies necessary fields (times, title, recurrence rules)
3. **Fix UID Conflicts**:
- Generate unique UID for exception event (exception-{uuid})
- Prevents CalDAV from treating exception as update to original series
- Original series keeps its UID, exception gets separate identity
4. **Correct Date/Time Handling**:
- Use occurrence_date for both this_only and this_and_future scopes
- Exception event now gets dragged date/time instead of original series date
- Properly reflects user's drag operation in the exception event
## Implementation Details:
- Exception event clones original with unique UID and RECURRENCE-ID
- Original series gets EXDATE to exclude the modified occurrence
- Main handler performs single atomic CalDAV update
- Smart field preservation (keeps original values when request is empty)
## Result:
Single occurrence modifications now work correctly with proper RFC 5545
EXDATE + exception event pattern, maintaining all event metadata while
reflecting user modifications at the correct date/time.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit resolves the "Failed to fetch" errors when updating recurring
event series through drag operations by implementing proper request
sequencing and fixing time parameter handling.
Key fixes:
- Eliminate HTTP request cancellation by sequencing operations properly
- Add global mutex to prevent CalDAV HTTP race conditions
- Implement complete RFC 5545-compliant series splitting for "this_and_future"
- Fix frontend to pass dragged times instead of original times
- Add comprehensive error handling and request timing logs
- Backend now handles both UPDATE (add UNTIL) and CREATE (new series) in single request
Technical changes:
- Frontend: Remove concurrent CREATE request, pass dragged times to backend
- Backend: Implement full this_and_future logic with sequential operations
- CalDAV: Add mutex serialization and detailed error tracking
- Series: Create new series with occurrence date + dragged times
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Extended update callback signature to include update_scope and occurrence_date parameters
- Modified app.rs to detect when series endpoint should be used vs regular endpoint
- Updated calendar_service to automatically set occurrence_date for "this_only" updates
- Modified all callback emit calls throughout frontend to include new parameters
- Week_view now properly calls series endpoint with "this_only" scope for single occurrence edits
This ensures that single occurrence modifications (RecurringEditAction::ThisEvent)
now go through the proper series endpoint which will:
- Add EXDATE to the original recurring series
- Create exception event with RECURRENCE-ID
- Show proper debug logging in backend
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- When dragging recurring events, preserve original series start date
- Only update time components, not date, to prevent series from shifting days
- For timed events: use original date with new start/end times from drag
- For all-day events: preserve original date and duration pattern
- Added debug logging to track date preservation behavior
- Maintains event duration for both timed and all-day recurring events
Fixes issue where dragging a recurring event would change the date
for all occurrences instead of just updating the time.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
