visit_time_ranges() reuses a single "original_duration" variable for two
unrelated purposes: the DTSTART->DUE span and the CREATED->COMPLETED span.
When a VTODO carries all four properties (a completed task, which most
clients write with CREATED and COMPLETED), the second assignment clobbers
the first, and the DTSTART/DUE branch of the rfc4791-9.9 table then
reconstructs DUE as DTSTART + (COMPLETED - CREATED).
The elif chain already implements the RFC table correctly (DTSTART/DUE
take precedence over CREATED/COMPLETED), so the CREATED/COMPLETED value
is never wanted there. Keep it in its own variable.
Effect: such a VTODO is filtered against a bogus interval, both in
calendar-query REPORT and in item.find_time_range() (the enclosing range
cached for the storage prefilter), so completed tasks go missing from -
or wrongly appear in - client results.
Co-Authored-By: Claude <noreply@anthropic.com>
_strip_single_event() removed the recurrence-defining properties (RRULE,
EXDATE, EXRULE, RDATE) with a single try/except around sequential
delattr() calls. When one of them was absent (e.g. an event with no
EXDATE), the AttributeError aborted the whole block and the following
properties -- notably RDATE -- were left on the expanded
single-occurrence VEVENTs returned by a calendar-data expand REPORT.
Remove each property independently so a missing one no longer prevents
removal of the others. Add a regression test and fixture.
Co-Authored-By: Claude <noreply@anthropic.com>
A calendar-query REPORT with a time-range filter failed to return a
VEVENT that has a whole-day DURATION (e.g. DURATION:P1D or P2D) whenever
the queried range fell inside the event but after DTSTART.
The VEVENT time-range logic in radicale/item/filter.py gated the
"non-zero duration" branch (rfc4791-9.9 line 2) on timedelta.seconds
instead of timedelta.total_seconds(). For a duration that is an exact
multiple of 24h, timedelta.seconds is 0 (the days component holds the
value), so the event was treated as zero-length (line 3) and only
matched a one-second window at its start. An identical event expressed
with DTEND matched correctly, confirming the defect is isolated to the
DURATION path.
Use total_seconds() so multi-day durations are handled correctly. Adds a
regression test (event11, DURATION:P2D) covering both an inside-range
match and an outside-range non-match.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Add CardDAV supported-address-data, update vCards to 4.0
- radicale/app/propfind.py: Add CS:getctag and CR:supported-address-data
properties to VADDRESSBOOK collections in allprop responses; implement
CR:supported-address-data handler that advertises vCard 4.0 as preferred
format with 3.0 fallback per RFC 6352 section 6.2.2
- radicale/tests/static/contact1.vcf: Update from vCard 3.0 to 4.0 format
- radicale/tests/static/contact_multiple.vcf: Update both contact entries
from vCard 3.0 to 4.0 format
- radicale/tests/static/contact_photo_with_data_uri.vcf: Update from vCard
3.0 to 4.0 format; change PHOTO property from 3.0 syntax with ENCODING=b
and TYPE parameters to 4.0 data URI syntax
* Conditionally offer vCard 4.0 based on vobject version
- Add vobject_supports_vcard4() helper function in utils.py
- Modify propfind.py to only advertise vCard 4.0 if vobject >= 1.0.0
- Add vCard 3.0 static test files for fallback testing
- Add tests for both vCard 3.0 and 4.0 contacts (v4 tests skipped if
vobject < 1.0.0)
- Add propfind tests for CR:supported-address-data property
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Default vCard fixtures to v3.0, add explicit v4 files
- contact1.vcf: Change VERSION from 4.0 to 3.0 to make vCard 3.0 the default
test fixture format, since vCard 3.0 is more widely supported
- contact1_v3.vcf: Delete file as contact1.vcf now serves as the v3.0 fixture
- contact1_v4.vcf: Add new file with VERSION 4.0 for explicit vCard 4.0
testing with vobject >= 1.0.0
- contact_multiple.vcf: Change VERSION from 4.0 to 3.0 for both contacts to
align with new default
- contact_multiple_v3.vcf: Delete file as contact_multiple.vcf now serves as
the v3.0 fixture
- contact_multiple_v4.vcf: Add new file with VERSION 4.0 for both contacts
- contact_photo_with_data_uri.vcf: Change VERSION from 4.0 to 3.0 and update
PHOTO property to use v3.0 format with ENCODING=b;TYPE=png parameters
- contact_photo_with_data_uri_v3.vcf: Delete file as
contact_photo_with_data_uri.vcf now serves as the v3.0 fixture
- contact_photo_with_data_uri_v4.vcf: Add new file with VERSION 4.0 and v4.0
PHOTO data URI format
- test_base.py: Update test methods to use renamed fixture files, with v3.0
tests using default fixtures and v4.0 tests using explicit _v4.vcf files
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
