Release 2.14.1 #72

Merged
makiolaj merged 15 commits from release/v2.14.1 into main 2026-07-13 13:48:23 +00:00

15 Commits

Author SHA1 Message Date
34fa9c9c3e chore(release): cut 2.14.1
All checks were successful
Translations / check (pull_request) Successful in 5s
CI / ci (pull_request) Successful in 8m43s
Move the Unreleased fixes (#47, #48, #49, #22) under a 2.14.1 heading, bump
versionName/versionCode to 2.14.1/21401, and sync the F-Droid per-version
changelog.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:32:16 +02:00
53793bfb68 docs(changelog): describe the .ics reminder prompt accurately (#49)
The prompt is raised whenever a default is configured and the file's reminders
differ from it — including when the file carries none at all, not only when it
brings its own. On-device verified.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:24:18 +02:00
9c7c8cb03a docs(changelog): note the #47 fix covers local calendars too
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:01:37 +02:00
4fea176e28 fix: drop occurrences via EXDATE on calendars with no _sync_id (#47)
The cancelled-exception fix works on synced calendars but not local ones. A
cancelled exception only attaches to its parent through ORIGINAL_SYNC_ID; a
local event has no _sync_id, so the link never forms and the provider's
expansion of the *parent* collapses — every other occurrence disappears, which
is the original #47 corruption, just on a different calendar type. Verified
on-device both ways: a DAVx5 series survives a single-occurrence delete, the
same series on a LOCAL calendar vanishes entirely.

deleteOccurrence now branches on _sync_id. Synced events keep the (verified)
exception path. Events without one — local calendars, and synced events not yet
pushed — add the occurrence to the master's EXDATE, which needs no parent link
and is the canonical iCalendar way to drop one; a sync adapter carries it
upstream unchanged if the calendar later syncs.

Two provider quirks shape the write (both observed on a Pixel):
- An EXDATE-only update is not treated as a recurrence change: the expanded
  Instances rows are left alone, so the occurrence stays visible. The
  time/recurrence set has to ride along to force re-expansion.
- DTSTART alone is worse — the provider then recomputes lastDate as if the event
  were a single instance and collapses the series to its first occurrence.
  DTSTART + DURATION + RRULE + zone together re-expand it correctly.

This path is reached in normal use: Calendula's own contact special-date
calendars are local and hold all-day yearly series, so deleting one birthday
occurrence went through it. All-day series take the VALUE=DATE EXDATE form.

Adds pure buildOccurrenceExdateValues + JVM tests (timed, append, duplicate
fold, all-day).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 15:01:11 +02:00
cf9492c7ba fix(detail): derive series length from DURATION when DTEND is null (#48)
A recurring series row carries DURATION, not DTEND, so EventDetailMapper's
end == begin fallback rendered it zero-length. That was harmless while every
caller supplied per-occurrence times from Instances, but the bare
content://…/events/<id> VIEW intent added in #48 names no occurrence and
keeps the row's own times — so a series opened from a third-party widget
without begin/end extras showed as "10:00 – 10:00".

Read DURATION in the detail projection and derive the end from it, the same
way SearchMapper and IcsExportMapper already do.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 12:55:05 +02:00
e6def9e5f7 docs(changelog): log the #47/#48/#49 fixes under Unreleased
The 2.14.1 branch carried four fixes but only the CalDAV colour picker
(#22) had a changelog entry. Adds the recurring single-instance delete
fix (#47), the external VIEW-intent handling (#48) and the default
reminder on ACTION_INSERT / .ics import prompt (#49), plus their issue
link definitions.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 12:34:08 +02:00
974185f354 Merge pull request 'fix(edit): default reminder for ACTION_INSERT events + import prompt (Codeberg #49)' (!71) from fix/insert-intent-default-reminder into release/v2.14.1
Reviewed-on: #71
2026-07-12 10:03:36 +00:00
6aacdd9111 feat(edit): offer default reminder on .ics import instead of auto-applying (#49)
All checks were successful
Translations / check (pull_request) Successful in 5s
CI / ci (pull_request) Successful in 5m21s
Split the two prefill paths that share openImported(): an ACTION_INSERT
intent still auto-applies the settings default (it carries no reminder
semantics), but a .ics file — which owns its reminders — no longer silently
decides. It keeps the file's reminders and raises a one-time prompt
("This event was imported with N reminder(s) — apply your default?") so the
user chooses. The prompt is skipped when there's no real choice: no default
configured, or the file already carries exactly it.

openImported() now takes an ImportSource; CalendarHost tags the overlay
Insert vs File. Accepting swaps in the default and reveals the section;
declining (or dismissing) keeps the file's own reminders.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-12 11:57:38 +02:00
4f263d00fe fix(edit): apply default reminder to ACTION_INSERT events (#49)
External ACTION_INSERT launches (e.g. Google Maps' "add to calendar",
the Todo Agenda widget) share the single-event .ics prefill channel:
CalendarHost routes requestedInsertForm as importForm, so EventEditScreen
calls openImported(), which froze reminders as touched to respect a file's
own VALARMs. But an insert intent carries no reminders, so the empty freeze
just suppressed the configured settings default — the event opened (and
saved) with no reminder.

Make the freeze follow the source, not the path: a form that carries its
own reminders (an .ics with VALARMs) still freezes them; a form with none
(every insert intent, and an .ics without VALARMs) falls back to the
settings default via applyDefaultReminder(), exactly like openNew(). An
intent that did carry reminders still wins.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-12 11:46:51 +02:00
bda002684c Merge pull request 'fix(edit): curate the CalDAV colour picker (#22)' (!70) from fix/caldav-color-picker-v2 into release/v2.14.1
Reviewed-on: #70
2026-07-12 09:40:18 +00:00
b6bcd195b0 fix(edit): curate the CalDAV colour picker (#22)
All checks were successful
CI / ci (pull_request) Successful in 5m18s
CalDAV sync adapters (DAVx5) publish all ~147 CSS3 named colours into
CalendarContract.Colors, so the event-colour picker showed a full screen
of alphabetically-scrambled, partly duplicated swatches.

Curation now runs in the space the picker actually paints — every swatch
is softened through pastelize, which pins lightness and caps saturation,
so the raw palette's lightness axis is invisible on screen. Judging
distinctness there: colours that paint identically collapse to one
(folding aliases, dark/light shades of a hue, and the neutrals together),
oversized palettes drop washed-out neutral-origin tints and thin by CIE76
ΔE in painted Lab, and survivors sort continuously by painted hue with the
wheel cut at its single widest gap. The CSS3 dump lands at ~33 distinct,
rainbow-ordered swatches; small hand-picked palettes (Google's) pass
through untouched. Every surviving swatch keeps its provider colour key so
picks still round-trip through sync.

This revives work stranded on fix/caldav-color-picker (never merged) and
adapts it to the floret-kit extraction of pastelize: the curation's
painted-space transform now lives self-contained in domain/pastelArgb as a
mirror of floret's pastelize shaping, rather than the two sharing one
function.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-12 11:22:04 +02:00
9fb4502ed0 Merge pull request 'fix: open existing events from external VIEW intents (Codeberg #48)' (!69) from fix/widget-view-event-intent into release/v2.14.1
Reviewed-on: #69
2026-07-12 09:09:24 +00:00
d398c72005 Merge pull request 'fix: cancel only the tapped occurrence on single-instance recurring delete (Codeberg #47)' (!68) from fix/recurring-single-delete into release/v2.14.1
Reviewed-on: #68
2026-07-12 09:09:07 +00:00
9d718e0f51 fix: open existing events from external VIEW intents (#48)
All checks were successful
CI / ci (pull_request) Successful in 10m20s
Follow-up to #30. v2.14.0 handles ACTION_INSERT (the widget "+"), but
tapping an existing event in a third-party widget (e.g. Todo Agenda) never
offered Calendula, because nothing handled ACTION_VIEW on
content://com.android.calendar/events/<id>.

- Manifest: add a VIEW intent-filter matched by the provider's item MIME
  type (vnd.android.cursor.item/event), mirroring AOSP Calendar and the
  sibling INSERT dir/event filter. A content: VIEW intent carries the
  resolved type, so a path-only filter wouldn't match it.
- MainActivity.viewEventKeyOrNull: parse the events URI into the existing
  occurrence detail-key channel (the one reminder taps use). Occurrence
  times ride as EXTRA_EVENT_BEGIN_TIME/END_TIME when the launcher supplies
  them; a bare URI omits them.
- EventDetailViewModel: a NO_OCCURRENCE_TIME sentinel makes loadDetail keep
  the event row's own DTSTART/DTEND for a bare URI instead of overriding to
  the epoch (would otherwise render at 1970).

Needs on-device verification (intent-filter matching + the widget's actual
extras).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-12 11:01:53 +02:00
2218c11d3f fix: cancel only the tapped occurrence on single-instance delete (#47)
All checks were successful
CI / ci (pull_request) Successful in 6m21s
"Delete only this event" on a recurring series wrote a cancelled
exception carrying just ORIGINAL_INSTANCE_TIME + STATUS_CANCELED. Without
DTSTART + DURATION the provider clones the master *with its RRULE intact*
and cancels the whole clone, so every other occurrence vanished, the
target survived as a "cancelled" ghost, and re-deleting toggled the
series back — exactly the reported corruption.

Anchor the exception as a single instance (DTSTART + DURATION + zone +
all-day, read from the series row) so the provider clears the inherited
RRULE and cancels only that occurrence — the same discipline the edit
path already documents (Codeberg #16). Also filter STATUS_CANCELED out of
the instances grid query so the cancelled occurrence disappears instead
of lingering as a tappable ghost (NULL status is kept — a normal event).

Extracts the exception ContentValues into a pure buildOccurrenceCancelValues
helper with JVM tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-12 10:36:35 +02:00