Discussion: Handle providers without MKCALENDAR support (Google Calendar) #21

New issue

Open

opened 2025-10-29 15:35:14 +00:00 by PhilflowIO · 0 comments

PhilflowIO commented

2025-10-29 15:35:14 +00:00

(Migrated from github.com)

Problem

Some CalDAV providers don't support automatic calendar creation via MKCALENDAR:

Google Calendar - Documented limitation (CalDAV v2 Guide)
RFC 4791: MKCALENDAR is RECOMMENDED, not REQUIRED

This affects migrations where target is Google Calendar or similar providers.

Current Behavior

Migration fails with error:

✗ Migration failed: Failed to create calendar: [calendar name]

Test Case

Issue #20 documents Baikal → Google Calendar migration test failure.

Proposed Solutions

Option 1: Pre-flight Check + User Guidance

Detect if target supports MKCALENDAR (via OPTIONS request)
If not supported:
- Show list of source calendars
- Prompt user to manually create calendars on target
- Wait for user confirmation
- Continue with migration using existing calendars

Option 2: Provider-Specific Calendar Mapping

Add config option for manual calendar mapping:

{
  "calendarMapping": {
    "source-calendar-name": "target-calendar-url-or-id",
    "Work Calendar": "https://calendar.google.com/.../events"
  }
}

Option 3: Use Provider REST API (Google-specific)

For Google: Fall back to Google Calendar REST API for calendar creation
Requires additional OAuth scopes
More complex, provider-specific code

Option 4: Fail Fast with Clear Instructions

Detect MKCALENDAR support before migration

If not supported, show clear error:

❌ Target provider (google) does not support automatic calendar creation.

Please manually create these calendars in Google Calendar:
1. "Work Calendar"
2. "Personal Calendar"

Then run: dav-migrate resume --state .migration-state.json

Recommendation

Option 1 (Pre-flight Check + User Guidance) seems most user-friendly:

Works with any provider
No provider-specific code
Clear user experience
Can be implemented in Phase 2

Discussion Questions

Which option do you prefer?
Should we support mixed scenarios (some calendars exist, some don't)?
Should calendar matching be by name or allow manual mapping?
Should we add a --skip-calendar-creation flag for this use case?

#20 - Baikal → Google test results

## Problem Some CalDAV providers don't support automatic calendar creation via `MKCALENDAR`: - **Google Calendar** - Documented limitation ([CalDAV v2 Guide](https://developers.google.com/workspace/calendar/caldav/v2/guide)) - RFC 4791: MKCALENDAR is `RECOMMENDED`, not `REQUIRED` This affects migrations where target is Google Calendar or similar providers. ### Current Behavior Migration fails with error: ``` ✗ Migration failed: Failed to create calendar: [calendar name] ``` ### Test Case Issue #20 documents Baikal → Google Calendar migration test failure. ## Proposed Solutions ### Option 1: Pre-flight Check + User Guidance - Detect if target supports MKCALENDAR (via OPTIONS request) - If not supported: - Show list of source calendars - Prompt user to manually create calendars on target - Wait for user confirmation - Continue with migration using existing calendars ### Option 2: Provider-Specific Calendar Mapping - Add config option for manual calendar mapping: ```json { "calendarMapping": { "source-calendar-name": "target-calendar-url-or-id", "Work Calendar": "https://calendar.google.com/.../events" } } ``` ### Option 3: Use Provider REST API (Google-specific) - For Google: Fall back to Google Calendar REST API for calendar creation - Requires additional OAuth scopes - More complex, provider-specific code ### Option 4: Fail Fast with Clear Instructions - Detect MKCALENDAR support before migration - If not supported, show clear error: ``` ❌ Target provider (google) does not support automatic calendar creation. Please manually create these calendars in Google Calendar: 1. "Work Calendar" 2. "Personal Calendar" Then run: dav-migrate resume --state .migration-state.json ``` ## Recommendation **Option 1 (Pre-flight Check + User Guidance)** seems most user-friendly: - Works with any provider - No provider-specific code - Clear user experience - Can be implemented in Phase 2 ## Discussion Questions 1. Which option do you prefer? 2. Should we support mixed scenarios (some calendars exist, some don't)? 3. Should calendar matching be by name or allow manual mapping? 4. Should we add a `--skip-calendar-creation` flag for this use case? ## Related - #20 - Baikal → Google test results