Files
calendula/docs
Jean-Luc Makiola 2ed18e9938 fix(import): make .ics import survive events the provider rejects (#225)
importEvents inserted every event in one unguarded loop, so a single row
the provider refused — it throws on a malformed RRULE straight out of
insert — aborted the batch and left the user with "couldn't read this
file" and nothing imported. Each event is now isolated and rejects are
counted into IcsImportSummary.failed and shown. sanitizeRrule drops empty
and malformed rule parts before the write.

Alongside that, several things a foreign file carries that we dropped:
VTODO components (silently lost, now imported as events), EXDATE, the
CATEGORIES calendar name, and colours — X-FOSSIFY-EVENT-COLOR / COLOR /
the category colour plus the X-SMT-* legacy spellings, snapped in Oklab
to the nearest key a palette account publishes since those reject a raw
EVENT_COLOR.

Two correctness fixes on our side: an all-day event may no longer end at
or before it starts (the provider expands a zero-length series into no
instances, so it just disappears), and imported all-day reminders now go
through the same encoding as hand-created ones instead of firing at UTC
midnight. A VALARM trigger pointing after the start is read as a time of
day rather than clamped to zero.

Note for later: their all-day DTEND is RFC-correct — endTS anchors at
noon of the last day and the exporter's +12h rounds it to the following
midnight. Do not "fix" it by sniffing PRODID; the holiday files bundled
in Fossify are conformant and name Fossify in theirs. One is kept as a
fixture.

Refs #225
2026-08-19 20:26:02 +02:00
..
2026-07-31 22:22:10 +02:00

Documentation map

Where to look for what:

Document What it is
../CONTRIBUTING.md How to contribute: issue-first workflow, which branch to target, translations, the rules a change is reviewed against
BUILDING.md Building from source: submodule, JDK/SDK requirements, Gradle tasks, what CI runs
ARCHITECTURE.md Orientation tour: principles, layers, navigation, recurring-write / conflict / reminder pipelines, testing
RELEASING.md Release process: versioning, the merge-driven pipeline, the two-forge split, secrets, key custody
../CHANGELOG.md Release history (Keep a Changelog, SemVer)
Issues + milestones The roadmap. What's planned, in progress, and shipped — a milestone maps to its release/vX.Y.Z branch
../.planning/PROJECT.md What the project is: core value, stack + version pins, constraints, naming, forge/release infrastructure
design/ Per-feature design notes kept for features whose provider behaviour is worth recording
../fastlane/metadata/android/ Store metadata (single source of truth): descriptions, title, icon, screenshots (DE + EN). Harvested directly by the official F-Droid repo; transformed into the self-hosted repo layout at release time by ../scripts/fastlane_to_fdroid_localized.sh
../fdroid-metadata/ App-level F-Droid control file (*.yml: Categories, License, links) for the self-hosted repo's fdroid update
fdroid-official/ Recipe + notes for publishing to the official F-Droid repo (reproducible build + developer-signed binary)

Conventions: planning lives in the issue tracker, not in this repository. The .planning/ files that predated it (a roadmap, a development-state snapshot, and a per-milestone requirement checklist) are gone — issues and milestones say the same thing without going stale. PROJECT.md is what remains, and it describes the project rather than its plan. ARCHITECTURE.md is the authoritative orientation tour: it is updated with the code, and is the right place for a lesson learned about the calendar provider.