CalDAV: tasks never reach Apple Reminders (Apple never syncs the reminders collection) #358

Closed
opened 2026-09-28 15:48:25 +00:00 by kayg · 11 comments
Owner

Bug (owner, 2026-09-28)

"Tasks don't seem to sync to Apple Calendar even though I have ticked Reminders there." Production account; the owner has at least one open task ("Buy milk", rich task file, no due date).

Evidence (Claude, macOS 27 VM against a local build with a logging proxy)

  • Reminders.app shows the account "calternal" with the list "Reminders", but the list is empty. (The test Home had no tasks, so this alone proves nothing.)
  • In the whole proxy log, Apple sent 16 PROPPATCH (calendar-color, calendar-order) to /dav/calendars/<u>/reminders/, each answered 207 with 403 propstats, and never a REPORT or a GET for the reminders collection. Journal got REPORT and PUT. Apple appears to retry the failed update and never reach the contents sync, so #355 (PROPPATCH 403) is the likely blocker.
  • macOS Calendar shows reminders only when they have a due date (scheduled reminders). An undated task appears only in Reminders.app. That is Apple behaviour; document it on the App Passwords setup screen.

Fix / prove

  1. After #355 merges: seed a test Home with tasks (dated, dated with time, undated, done, recurring, subtask), connect the Mac, and prove with the proxy log that Apple sends REPORT/GET for reminders and that Reminders.app and Calendar (dated ones) show them. Capture the requests as fixtures in crates/calternal-dav/tests/fixtures/macos27/.
  2. If Apple still does not sync: compare our PROPFIND on the calendar home with a known-good server (Radicale/Baikal shapes): supported-calendar-component-set VTODO, getctag, sync-token, supported-report-set (sync-collection, calendar-query, calendar-multiget), resourcetype, current-user-privilege-set.
  3. Round-trip from Apple: complete a reminder, rename it, set a due date, create a new one; check the Markdown result.
  4. One task identity: coordinate with #357 (a rich task must be one VTODO, not two).

Claude verifies on the VM before telling the owner.

## Bug (owner, 2026-09-28) "Tasks don't seem to sync to Apple Calendar even though I have ticked Reminders there." Production account; the owner has at least one open task ("Buy milk", rich task file, no due date). ## Evidence (Claude, macOS 27 VM against a local build with a logging proxy) - Reminders.app shows the account "calternal" with the list "Reminders", but the list is empty. (The test Home had no tasks, so this alone proves nothing.) - In the whole proxy log, Apple sent 16 PROPPATCH (calendar-color, calendar-order) to `/dav/calendars/<u>/reminders/`, each answered 207 with 403 propstats, and **never a REPORT or a GET** for the reminders collection. Journal got REPORT and PUT. Apple appears to retry the failed update and never reach the contents sync, so #355 (PROPPATCH 403) is the likely blocker. - macOS Calendar shows reminders only when they have a due date (scheduled reminders). An undated task appears only in Reminders.app. That is Apple behaviour; document it on the App Passwords setup screen. ## Fix / prove 1. After #355 merges: seed a test Home with tasks (dated, dated with time, undated, done, recurring, subtask), connect the Mac, and prove with the proxy log that Apple sends REPORT/GET for reminders and that Reminders.app and Calendar (dated ones) show them. Capture the requests as fixtures in `crates/calternal-dav/tests/fixtures/macos27/`. 2. If Apple still does not sync: compare our PROPFIND on the calendar home with a known-good server (Radicale/Baikal shapes): `supported-calendar-component-set` VTODO, `getctag`, `sync-token`, `supported-report-set` (sync-collection, calendar-query, calendar-multiget), `resourcetype`, `current-user-privilege-set`. 3. Round-trip from Apple: complete a reminder, rename it, set a due date, create a new one; check the Markdown result. 4. One task identity: coordinate with #357 (a rich task must be one VTODO, not two). Claude verifies on the VM before telling the owner.
Author
Owner

Proven on the macOS 27 VM (Claude, 2026-09-29 02:00)

With #355 merged: Apple's PROPPATCH now gets 200 and Apple now syncs the reminders collection (sync-collection REPORT 207). This confirms #355 was the blocker for #358.

New defect: creating a reminder in Reminders.app fails with 422 "exactly one VTODO is required". Apple's PUT (exact body attached as the fixture crates/calternal-dav/tests/fixtures/macos27/put-new-reminder.ics in the job branch; copy from the comment below) contains:

  • a VTIMEZONE component (Asia/Calcutta, with RDATE lines) next to the VTODO;
  • a nested VALARM (ACTION:DISPLAY, TRIGGER;VALUE=DATE-TIME, UID, X-WR-ALARMUID) inside the VTODO;
  • DTSTART;TZID=… and DUE;TZID=… with a timezone parameter; CREATED, LAST-MODIFIED, DTSTAMP.

Fix

  • Count only VTODO components; accept and apply VTIMEZONE (resolve TZID for DUE/DTSTART; the Task stores its zone per DESIGN C12); accept VALARM and map a DISPLAY alarm at an absolute time (or relative to DUE) to a block reminder (DESIGN §42 calternal-reminders), or preserve it losslessly if the mapping is ambiguous. Never 422 a normal Apple reminder.
  • Unknown X- properties: preserve or ignore; do not reject.
  • DTSTART on a task maps to the scheduled date (DESIGN §31 task model), DUE to the due date.
  • Round trip: create, edit title, set due, complete, delete from Reminders.app; each change lands in Markdown correctly and syncs back (ETag changes, sync-token advances).
  • Seed a test Home with tasks (dated, dated+time, undated, done, recurring, subtask) and prove with a replay test that the REPORT returns them in the shape Apple accepts.
  • Regression: the attached Apple body must PUT with 201 and produce a Task file.

Claude verifies on the macOS VM after merge.

## Proven on the macOS 27 VM (Claude, 2026-09-29 02:00) With #355 merged: Apple's PROPPATCH now gets 200 and **Apple now syncs the reminders collection** (sync-collection REPORT 207). This confirms #355 was the blocker for #358. **New defect: creating a reminder in Reminders.app fails with 422 "exactly one VTODO is required".** Apple's PUT (exact body attached as the fixture `crates/calternal-dav/tests/fixtures/macos27/put-new-reminder.ics` in the job branch; copy from the comment below) contains: - a `VTIMEZONE` component (Asia/Calcutta, with RDATE lines) next to the VTODO; - a nested `VALARM` (ACTION:DISPLAY, TRIGGER;VALUE=DATE-TIME, UID, X-WR-ALARMUID) inside the VTODO; - `DTSTART;TZID=…` and `DUE;TZID=…` with a timezone parameter; `CREATED`, `LAST-MODIFIED`, `DTSTAMP`. ## Fix - Count only VTODO components; accept and apply VTIMEZONE (resolve TZID for DUE/DTSTART; the Task stores its zone per DESIGN C12); accept VALARM and map a DISPLAY alarm at an absolute time (or relative to DUE) to a block reminder (DESIGN §42 `calternal-reminders`), or preserve it losslessly if the mapping is ambiguous. Never 422 a normal Apple reminder. - Unknown X- properties: preserve or ignore; do not reject. - DTSTART on a task maps to the scheduled date (DESIGN §31 task model), DUE to the due date. - Round trip: create, edit title, set due, complete, delete from Reminders.app; each change lands in Markdown correctly and syncs back (ETag changes, sync-token advances). - Seed a test Home with tasks (dated, dated+time, undated, done, recurring, subtask) and prove with a replay test that the REPORT returns them in the shape Apple accepts. - Regression: the attached Apple body must PUT with 201 and produce a Task file. Claude verifies on the macOS VM after merge.
Author
Owner

Apple Reminders PUT body captured on the macOS 27 VM (fixture for #358):

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Apple Inc.//iOS 27.0//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Asia/Calcutta
BEGIN:STANDARD
DTSTART:19420515T000000
RDATE:19420515T000000
RDATE:19451015T000000
TZNAME:IST
TZOFFSETFROM:+0630
TZOFFSETTO:+0530
END:STANDARD
END:VTIMEZONE
BEGIN:VTODO
CREATED:20260929T000004Z
DTSTAMP:20260929T000007Z
DTSTART;TZID=Asia/Calcutta:20260929T063004
DUE;TZID=Asia/Calcutta:20260929T063004
LAST-MODIFIED:20260929T000004Z
STATUS:NEEDS-ACTION
SUMMARY:Night verify reminder
UID:4A1C73E2-1C8A-41A1-8281-C44D02887069
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Reminder
TRIGGER;VALUE=DATE-TIME:20260929T010004Z
UID:567E7B5A-DE34-42BB-935A-AC206BAEDB57
X-WR-ALARMUID:567E7B5A-DE34-42BB-935A-AC206BAEDB57
END:VALARM
END:VTODO
END:VCALENDAR
Apple Reminders PUT body captured on the macOS 27 VM (fixture for #358): ``` BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Apple Inc.//iOS 27.0//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Asia/Calcutta BEGIN:STANDARD DTSTART:19420515T000000 RDATE:19420515T000000 RDATE:19451015T000000 TZNAME:IST TZOFFSETFROM:+0630 TZOFFSETTO:+0530 END:STANDARD END:VTIMEZONE BEGIN:VTODO CREATED:20260929T000004Z DTSTAMP:20260929T000007Z DTSTART;TZID=Asia/Calcutta:20260929T063004 DUE;TZID=Asia/Calcutta:20260929T063004 LAST-MODIFIED:20260929T000004Z STATUS:NEEDS-ACTION SUMMARY:Night verify reminder UID:4A1C73E2-1C8A-41A1-8281-C44D02887069 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:Reminder TRIGGER;VALUE=DATE-TIME:20260929T010004Z UID:567E7B5A-DE34-42BB-935A-AC206BAEDB57 X-WR-ALARMUID:567E7B5A-DE34-42BB-935A-AC206BAEDB57 END:VALARM END:VTODO END:VCALENDAR ```
Author
Owner

Started work on job/reminders-sync from dev at 94f1cfd5b034b2a2da5c8143ddc0fcc28f9d2ac1 (base and starting head). I read the full issue thread; the new reproduction is Apple's VTODO inside a VCALENDAR that also has VTIMEZONE and nested VALARM. I am tracing the current parser and VEVENT timezone path before changing it.

Started work on `job/reminders-sync` from `dev` at `94f1cfd5b034b2a2da5c8143ddc0fcc28f9d2ac1` (base and starting head). I read the full issue thread; the new reproduction is Apple's VTODO inside a VCALENDAR that also has VTIMEZONE and nested VALARM. I am tracing the current parser and VEVENT timezone path before changing it.
Author
Owner

Finding: the captured fixture has one direct VTODO plus VTIMEZONE/STANDARD and VTODO/VALARM children. The new regression fails with exactly one VTODO is required because parse_reminder_icalendar requires calendar.components.len() == 2, which counts the entire parsed tree. I am changing the parser to count only direct VTODO children and validate the allowed timezone and alarm components.

Finding: the captured fixture has one direct VTODO plus VTIMEZONE/STANDARD and VTODO/VALARM children. The new regression fails with `exactly one VTODO is required` because `parse_reminder_icalendar` requires `calendar.components.len() == 2`, which counts the entire parsed tree. I am changing the parser to count only direct VTODO children and validate the allowed timezone and alarm components.
Author
Owner

Finding: the parser and DAV metadata retained Apple's Asia/Calcutta value, but GET lost the time. The Task file builder accepts minute precision and appends :00; passing Apple's 06:30:04 produced 06:30:04:00, so the index dropped the time suffix. I am keeping the shared builder contract intact and writing the complete DAV date-time scalar in the Notes provider.

Finding: the parser and DAV metadata retained Apple's Asia/Calcutta value, but GET lost the time. The Task file builder accepts minute precision and appends `:00`; passing Apple's `06:30:04` produced `06:30:04:00`, so the index dropped the time suffix. I am keeping the shared builder contract intact and writing the complete DAV date-time scalar in the Notes provider.
Author
Owner

Completed #358 on job/reminders-sync.

Head: f48f6863f133b1f0bb00dafcc87cc75ed7ceab6b
Commits: c81ecf99 (accept Apple VTODO timezone and alarm payloads), 7e929c18 (persist Apple reminder zones and alarms in Tasks), then merge of local dev.

What changed

  • Added the exact macOS 27 PUT fixture with CRLF line endings. The production DAV router now accepts it with 201, and GET preserves the UID, local timezone dates and VALARM.
  • Count direct VTODO children while accepting bounded VTIMEZONE siblings and nested VALARMs. Validate IANA TZIDs and their local times. Ignore unknown X-properties.
  • Persist per-resource timezone, VALARM and case-only Apple UUID metadata in Task frontmatter and its rebuildable Index projection. Keep the canonical lowercase calternal-id stable.
  • Added a seeded reminders REPORT replay for dated, timed, undated, done, recurring, parent and subtask resources; exercised title, due date, completion, ETag, sync-token and delete/tombstone round trips.
  • Adversarial replay: 17 VALARMs and bogus TZIDs return 422; 1,000 X-properties are accepted; a request for another user's reminders path returns 403.

Decisions not specified in DESIGN

Task timezone and alarm persistence has no defined Markdown field. I used the calternal-dav frontmatter map, keyed by resource UID, so a rich Task and its child reminders can retain distinct DAV state without changing the shared Task schema. VALARMs are stored as bounded raw iCalendar components because an ambiguous alarm cannot be mapped safely to the current Task model. Apple’s uppercase UUID remains the DAV resource UID; the Task identity stays canonical lowercase.

Verification

Focused results:

12 passed; 0 failed (calternal-dav unit tests)
5 passed; 0 failed (Apple DAV replay tests)
1 passed; 0 failed (Notes reminder provider round trip)

Final gate output excerpts, verbatim:

$ cargo fmt --check
[exit 0; no output]

$ cargo clippy --all-targets -- -D warnings
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 47.22s

$ cargo test
failures:
    connection_resets_retry_safe_read_requests
    limited_ls_preserves_the_cursor_in_json_and_reports_the_count_in_human_output
    ls_follows_all_pages_and_returns_a_complete_json_listing

test result: FAILED. 12 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.30s
error: test failed, to rerun pass `-p calternal-cli --test output_contract`

$ bun run check
/home/kayg/Developer/calternal-wt/reminders-sync/apps/web/src/lib/themes.test.ts:278:21
Error: Object is possibly 'undefined'.
      expect(found, `--layer-${name} defined once`).toHaveLength(1);
      return Number(found[0][1]);
svelte-check found 1 error and 0 warnings in 1 file
error: script "check" exited with code 1

$ bun run build
✓ built in 1m 34s
  Wrote site to "build"

$ bun run test
 Test Files  118 passed (118)
      Tests  767 passed (767)

The workspace cargo test stopped in unrelated CLI localhost-request tests; the Notes package tests passed (60 passed in this run). The web check diagnostic is in an untouched test file. The macOS 27 VM verification remains with Claude.

cargo clean output: Removed 15539 files, 11.9GiB total. Generated web build output and installed node_modules were removed. Pushed job/reminders-sync; push reported Everything up-to-date.

Completed #358 on `job/reminders-sync`. Head: `f48f6863f133b1f0bb00dafcc87cc75ed7ceab6b` Commits: `c81ecf99` (accept Apple VTODO timezone and alarm payloads), `7e929c18` (persist Apple reminder zones and alarms in Tasks), then merge of local `dev`. ## What changed - Added the exact macOS 27 PUT fixture with CRLF line endings. The production DAV router now accepts it with 201, and GET preserves the UID, local timezone dates and VALARM. - Count direct VTODO children while accepting bounded VTIMEZONE siblings and nested VALARMs. Validate IANA TZIDs and their local times. Ignore unknown X-properties. - Persist per-resource timezone, VALARM and case-only Apple UUID metadata in Task frontmatter and its rebuildable Index projection. Keep the canonical lowercase `calternal-id` stable. - Added a seeded reminders REPORT replay for dated, timed, undated, done, recurring, parent and subtask resources; exercised title, due date, completion, ETag, sync-token and delete/tombstone round trips. - Adversarial replay: 17 VALARMs and bogus TZIDs return 422; 1,000 X-properties are accepted; a request for another user's reminders path returns 403. ## Decisions not specified in DESIGN Task timezone and alarm persistence has no defined Markdown field. I used the `calternal-dav` frontmatter map, keyed by resource UID, so a rich Task and its child reminders can retain distinct DAV state without changing the shared Task schema. VALARMs are stored as bounded raw iCalendar components because an ambiguous alarm cannot be mapped safely to the current Task model. Apple’s uppercase UUID remains the DAV resource UID; the Task identity stays canonical lowercase. ## Verification Focused results: ```text 12 passed; 0 failed (calternal-dav unit tests) 5 passed; 0 failed (Apple DAV replay tests) 1 passed; 0 failed (Notes reminder provider round trip) ``` Final gate output excerpts, verbatim: ```text $ cargo fmt --check [exit 0; no output] $ cargo clippy --all-targets -- -D warnings Finished `dev` profile [unoptimized + debuginfo] target(s) in 47.22s $ cargo test failures: connection_resets_retry_safe_read_requests limited_ls_preserves_the_cursor_in_json_and_reports_the_count_in_human_output ls_follows_all_pages_and_returns_a_complete_json_listing test result: FAILED. 12 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.30s error: test failed, to rerun pass `-p calternal-cli --test output_contract` $ bun run check /home/kayg/Developer/calternal-wt/reminders-sync/apps/web/src/lib/themes.test.ts:278:21 Error: Object is possibly 'undefined'. expect(found, `--layer-${name} defined once`).toHaveLength(1); return Number(found[0][1]); svelte-check found 1 error and 0 warnings in 1 file error: script "check" exited with code 1 $ bun run build ✓ built in 1m 34s Wrote site to "build" $ bun run test Test Files 118 passed (118) Tests 767 passed (767) ``` The workspace cargo test stopped in unrelated CLI localhost-request tests; the Notes package tests passed (`60 passed` in this run). The web check diagnostic is in an untouched test file. The macOS 27 VM verification remains with Claude. `cargo clean` output: `Removed 15539 files, 11.9GiB total`. Generated web build output and installed `node_modules` were removed. Pushed `job/reminders-sync`; push reported `Everything up-to-date`.
Author
Owner

Verified on macOS 27 (Claude, 2026-09-29 05:16)

With #358 merged: creating a reminder in Reminders.app now works (PUT 201; a Markdown task with title, scheduled, due and the DAV metadata is created and attached to the Daily note).

New defect: completing the reminder fails with 422 "unsupported VTODO property". Apple sends COMPLETED:<utc>, PERCENT-COMPLETE:100 and STATUS:COMPLETED. Fix: map STATUS:COMPLETED / COMPLETED to status done (with the completion time), IN-PROCESS to doing, CANCELLED to cancelled; PERCENT-COMPLETE is derived. More important: never reject a normal Apple property. Unknown properties are preserved losslessly in the existing calternal-dav frontmatter map (as the VALARM is) or ignored; a 422 is only for malformed iCalendar. Also cover: rename, change due, delete, uncomplete, flag (X-APPLE-… / PRIORITY), notes (DESCRIPTION), URL, subtasks (RELATED-TO).

Exact Apple completion body (fixture put-complete-reminder.ics):

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Apple Inc.//iOS 27.0//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Asia/Calcutta
BEGIN:STANDARD
DTSTART:19420515T000000
RDATE:19420515T000000
RDATE:19451015T000000
TZNAME:IST
TZOFFSETFROM:+0630
TZOFFSETTO:+0530
END:STANDARD
END:VTIMEZONE
BEGIN:VTODO
COMPLETED:20260929T031610Z
CREATED:20260929T031507Z
DTSTAMP:20260929T031611Z
DTSTART;TZID=Asia/Calcutta:20260929T104507
DUE;TZID=Asia/Calcutta:20260929T104507
LAST-MODIFIED:20260929T031610Z
PERCENT-COMPLETE:100
STATUS:COMPLETED
SUMMARY:Morning check reminder
UID:3F044668-801E-411E-BB4C-BF20906FD870
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Reminder
TRIGGER;VALUE=DATE-TIME:20260929T051507Z
UID:8A74D169-BA1F-47CE-A216-52622C8E2CF6
X-WR-ALARMUID:8A74D169-BA1F-47CE-A216-52622C8E2CF6
END:VALARM
END:VTODO
END:VCALENDAR
## Verified on macOS 27 (Claude, 2026-09-29 05:16) With #358 merged: **creating a reminder in Reminders.app now works** (PUT 201; a Markdown task with title, scheduled, due and the DAV metadata is created and attached to the Daily note). **New defect: completing the reminder fails with 422 "unsupported VTODO property".** Apple sends `COMPLETED:<utc>`, `PERCENT-COMPLETE:100` and `STATUS:COMPLETED`. Fix: map STATUS:COMPLETED / COMPLETED to status done (with the completion time), IN-PROCESS to doing, CANCELLED to cancelled; PERCENT-COMPLETE is derived. More important: **never reject a normal Apple property**. Unknown properties are preserved losslessly in the existing `calternal-dav` frontmatter map (as the VALARM is) or ignored; a 422 is only for malformed iCalendar. Also cover: rename, change due, delete, uncomplete, flag (`X-APPLE-…` / PRIORITY), notes (DESCRIPTION), URL, subtasks (RELATED-TO). Exact Apple completion body (fixture `put-complete-reminder.ics`): ``` BEGIN:VCALENDAR CALSCALE:GREGORIAN PRODID:-//Apple Inc.//iOS 27.0//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Asia/Calcutta BEGIN:STANDARD DTSTART:19420515T000000 RDATE:19420515T000000 RDATE:19451015T000000 TZNAME:IST TZOFFSETFROM:+0630 TZOFFSETTO:+0530 END:STANDARD END:VTIMEZONE BEGIN:VTODO COMPLETED:20260929T031610Z CREATED:20260929T031507Z DTSTAMP:20260929T031611Z DTSTART;TZID=Asia/Calcutta:20260929T104507 DUE;TZID=Asia/Calcutta:20260929T104507 LAST-MODIFIED:20260929T031610Z PERCENT-COMPLETE:100 STATUS:COMPLETED SUMMARY:Morning check reminder UID:3F044668-801E-411E-BB4C-BF20906FD870 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:Reminder TRIGGER;VALUE=DATE-TIME:20260929T051507Z UID:8A74D169-BA1F-47CE-A216-52622C8E2CF6 X-WR-ALARMUID:8A74D169-BA1F-47CE-A216-52622C8E2CF6 END:VALARM END:VTODO END:VCALENDAR ```
Author
Owner

Started continuation on job/reminders-sync at f48f6863f1; dev is at 89b3f1f2c2. The prior Apple VTODO work is already merged into dev. I am merging current dev into this branch before changes. Latest Claude comment shows completion PUT rejected for COMPLETED, PERCENT-COMPLETE and STATUS:COMPLETED; I will save its exact body as a CRLF fixture and fix property handling.

Started continuation on job/reminders-sync at f48f6863f133b1f0bb00dafcc87cc75ed7ceab6b; dev is at 89b3f1f2c2186c854ebd0ec55c0d27085967fca6. The prior Apple VTODO work is already merged into dev. I am merging current dev into this branch before changes. Latest Claude comment shows completion PUT rejected for COMPLETED, PERCENT-COMPLETE and STATUS:COMPLETED; I will save its exact body as a CRLF fixture and fix property handling.
Author
Owner

Finding: the current parser returns for unhandled fields such as DESCRIPTION and PERCENT-COMPLETE, silently skips unknown X-properties, and stores COMPLETED only as a date. The Notes writer has no DESCRIPTION body mapping. I am extending the existing per-resource calternal-dav metadata and Task body writer so these fields round-trip.

Finding: the current parser returns for unhandled fields such as DESCRIPTION and PERCENT-COMPLETE, silently skips unknown X-properties, and stores COMPLETED only as a date. The Notes writer has no DESCRIPTION body mapping. I am extending the existing per-resource calternal-dav metadata and Task body writer so these fields round-trip.
Author
Owner

Correction to my previous comment: shell quoting removed the error text. The parser returns unsupported VTODO property for unhandled fields such as DESCRIPTION and PERCENT-COMPLETE, silently skips unknown X-properties, and stores COMPLETED only as a date. The Notes writer has no DESCRIPTION body mapping. I am extending the existing per-resource calternal-dav metadata and Task body writer so these fields round-trip.

Correction to my previous comment: shell quoting removed the error text. The parser returns unsupported VTODO property for unhandled fields such as DESCRIPTION and PERCENT-COMPLETE, silently skips unknown X-properties, and stores COMPLETED only as a date. The Notes writer has no DESCRIPTION body mapping. I am extending the existing per-resource calternal-dav metadata and Task body writer so these fields round-trip.
Author
Owner

Fixed in 12da5286a and a214ebec7 (origin/dev); the Reminders collection and completion round trips are covered by the DAV replay tests.

Fixed in 12da5286a and a214ebec7 (origin/dev); the Reminders collection and completion round trips are covered by the DAV replay tests.
kayg closed this issue 2026-10-03 11:55:32 +00:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#358
No description provided.