[Feature] Create Calendar Event and keep it synced

[flow10]

Currently it is possible to import an existing calendar event and keep it synced.
It would be very handy if it would also work the other way around: On creating a date in the attendance app automatically create a date in the calendar app and keep it synced.

Use case: In my big band we have a shared calendar with all events which are relevant for the band and we would like to see all "attendance app dates" there, too. In the current version this would require two steps: Creating the event in the calendar and then import it to the attendance app. Maybe we could get around this extra step?

Thank you by the way for this fantastic app!

[luflow]

Thanks for the kind words and the clear use case — accepted! 🎉 The shared band calendar scenario is exactly what this feature should solve. Here is the plan and the known pitfalls, so the scope is transparent.

Plan

Phase 1 — Create & link (calendar → app sync comes for free)

• New option in the appointment form: "Create event in calendar" with a picker of the user's writable calendars (ICalendarIsWritable).
• The app builds the VEVENT (via ICalendarEventBuilder / ICreateFromString) and stores calendarUri + calendarEventUid on the appointment — the same link the import flow already uses.
• Because the existing CalendarObjectUpdateListener matches purely on that link, calendar → app sync (title, description, times, deletion) works automatically for app-created events. Zero extra code for that direction.

Phase 2 — Push app edits back to the calendar (true two-way)

• When an appointment with a linked event is edited in the app (title, description, start/end, cancellation), patch the linked VEVENT.
• Implementation detail: read the existing ICS and patch only the changed properties instead of rebuilding the object — this preserves anything the app doesn't model (formatted descriptions, alarms, attendees, etc.).

New capability flag in getCapabilities() so older mobile clients don't show the option against older servers.

Pitfalls we need to handle

1. Echo loop: writing to the calendar fires CalendarObjectUpdatedEvent, which our own listener picks up and syncs back. Harmless for field updates (idempotent), but dangerous for deletions — our own handleDelete would soft-delete the appointment. Needs an "this change originated from us" suppression marker.
2. Lossy description: the app stores plain text (the listener strips HTML on import). Naively replacing the whole VEVENT would overwrite formatted calendar descriptions with the stripped version on every roundtrip — hence the property-patching approach above.
3. User context for writes: reading happens passively and system-wide; writing only works as a specific user into a calendar they can write to. If a different manager edits the appointment and has no access to the linked calendar, the write can't happen — this needs defined behaviour (e.g. a sync status indicator instead of silent failure).
4. iMIP side effects: createFromString runs through the full CalDAV stack including the iMIP plugin — if the event has attendees, update emails may go out. createFromStringMinimal avoids this but only exists since NC 32, while we support NC 31+ — so this needs a version gate/fallback.

Out of scope for now: writing back into imported recurring series (that would require creating RECURRENCE-ID exceptions — the current occurrence matching is heuristic and not solid enough for writes). App-created single events, which is your use case, are not affected by this.