An iCal subscription could be banished but never un-banished. The server has
always sent and accepted sidebar_hidden for subscriptions, but iOS left the
field off ICalSubscription entirely and omitted "ical" from
serverManagedSources, from setCalendarSidebarHidden and from both places that
reconcile the server's flag. So the key went into banishedCalendarKeys and
nothing ever took it out: refreshFromCache filters on that set as well as on
hiddenCalendarKeys, which is why showing the calendar again left its events
invisible and no amount of syncing helped. Closed on all four sides.
The account models are also no longer brittle about absent fields.
HomeAssistantAccount required auth_method, and CalDAVCalendar and
GoogleCalendar required sidebar_hidden, with no custom decoder — one missing
key threw, the `try?` at the call site turned that into an empty list, and the
reconciliation silently did not run, stranding calendars as banished in exactly
the same way. HACalendar already carried a lenient decoder for this reason; the
other three now do too.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The monorepo's Xcode project referenced ../CalendarrKit, but the package was
never brought across: it is the one repo that never had a remote, so it existed
only on one machine. Added as a subtree at the root, where that existing
relative path resolves, so the project needs no change. History is preserved —
the commits explaining why the snapshot colours sit flat on the wire and why
the package must stay Foundation-only are the kind of thing that cannot be
reconstructed later.
The iOS target also did not compile on beta, independent of any of this. The
attachments section combined a string title with a footer, and SwiftUI has no
initializer for that pair: the title then binds as the first positional
argument of Section(content:footer:), which is what the three misleading
"generic parameter 'Content'" errors were. Rewritten as header:/footer:, the
way the reminders section directly above already does it.
Carries over the pending change from the archived iOS repo: each calendar
source now reports its own failure instead of being swallowed by `try?`, so an
absent Home Assistant calendar can finally be diagnosed from the app.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
attachmentCount im Event-Parser, EventAttachment als Modell, API-Methoden
fuer Liste, Upload, Download, Thumbnail und Loeschen. Der Multipart-Body
ist von importICS uebernommen.
Die Detailansicht laedt die Liste beim Oeffnen und teilt eine Datei ueber
das System-Share-Sheet; der Editor staged neue Dateien und wendet sie
erst nach dem Speichern an, weil ein neuer Termin vorher keine UID hat.
EventAttachment liegt bewusst in CalEvent.swift statt in einer eigenen
Datei: eine hier angelegte .swift-Datei waere in keinem Xcode-Target
Mitglied und wuerde schlicht nicht mitkompiliert -- das faellt erst auf
dem Mac auf.
Die URL fuer das Share-Sheet steckt in einem kleinen Identifiable-Wrapper,
weil URL das nicht ist und eine nachtraegliche Konformitaet auf einen
Stdlib-Typ modulweit sichtbar waere.
Nicht kompiliert: auf diesem Rechner gibt es kein Xcode. Muss auf dem Mac
gebaut werden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Calendarr-IOS wird mit vollstaendiger Historie als Unterverzeichnis
ios/ eingebunden. Damit liegen Server, Web, Android und iOS in einem
gemeinsamen Repo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ScarriffleandClaude Opus 5
ScarriffleandClaude Opus 5