You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
New "features" added:
* 'save-load.mutable' (replaces an old "compatibility flag", this has been observed unsupported for the old google API, long time ago)
Compatibilities changed:
* search.recurrences.expanded.exception was wrongly taggd as
unsupported on many servers due to a bug in the checker script.
Other:
The old unique_calendar_ids "compatibility flag" seems not to be needed anymore by any servers I test, so it was removed (but possibly we will need it at some point in the future ...).
AI-disclaimer:
The unique_calendar_ids yanking job was hand-made, the other was
AI-generated. The compatibility_hints.py is one of the places where
AI-maintenance is considered OK. It's not considered to be a part of
the sharp edge of the library, and some of the updates may be tedious.
prompt: Create tests for a new feature checking if it's possible to
overwrite a calendar event with new data. Should replace the old
"overwrite" compatibility flag. (Perhaps this "incompatibility" was due
to the caldav library not supporting etags and not updating from no
sequence to SEQUENCE:1 ... i somehow doubt we'll find any servers not
supporting this feature, but we should have the check anyway).
load-save.mutable ? Update the compatibility_hints.py in
/tmp/caldav-async-tests/ and update the tests there as well.
prompt: On the main branch in the current directory, we get
AssertionError: expectation is unsupported, observation is full for
search.recurrences.expanded.exception from many servers now when running
pytest -k compat in ~/caldav. Reproducable by doing cd ~/caldav ; status=good ;
pytest tests/test_caldav.py::TestForServerRadicale::testCheckCompatibility ||
status=bad; cd ~/caldav-server-tester ; echo $status. Checking out tag v3.2.0,
the test passes. There aren't that many differences between main and v3.2.0.
Please investigate.
followup-prompt: Throw it into the current async-test-infrastructure branch.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: caldav/compatibility_hints.py
+11-18Lines changed: 11 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -77,6 +77,9 @@ class FeatureSet:
77
77
## TODO: in the future, templates for the principal URL, calendar URLs etc may also be added.
78
78
}
79
79
},
80
+
"url": {
81
+
"type": "client-hints",
82
+
},
80
83
"get-current-user-principal": {
81
84
"description": "Support for RFC5397, current principal extension. Most CalDAV servers have this, but it is an extension to the DAV standard. Possibly observed missing on mail.ru, DavMail gateway and it is possible to configure the support in some sabre-based servers",
"description": "A saved calendar object resource can be modified and PUT back to the server; the server accepts the update and returns the modified data on the next GET/REPORT. When 'unsupported', the server treats calendar objects as immutable after initial creation (e.g. Google Calendar's legacy CalDAV API). Replaces the old 'no_overwrite' compatibility flag.",
185
+
"default": {"support": "full"},
186
+
},
180
187
"search": {
181
188
"description": "calendar MUST support searching for objects using the REPORT method, as specified in RFC4791, section 7",
## I'm surprised, I'm quite sure this was reported ungraceful earlier. Passed with caldav commit a98d50490b872e9b9d8e93e2e401c936ad193003, caldav server checker commit 3cae24cf99da1702b851b5a74a9b88c8e5317dad 2026-02-15. The commit 3cae24cf99da1702b851b5a74a9b88c8e5317dad was however development done on the wrong branch and has been force-pushed awway. It was again observed ungraceful at commits be26d42b1ca3ff3b4fd183761b4a9b024ce12b84 / 537a23b145487006bb987dee5ab9e00cdebb0492
0 commit comments