No announcement yet.

OX caldav text-match/collation search support?

  • Filter
  • Time
  • Show
Clear All
new posts

  • OX caldav text-match/collation search support?

    Hi all,

    Does the CalDav interface of the OX App Suite support text-match with collation (RFC)?
    Quickly looking at the code, I found:Am I missing something or is it not supported?

    Thanks in advance,

    Context: the client I'm using is doing a UID search and is getting more that it should, as far as I understand.
    I've written a small piece of python3 script using python-caldav (attached) that does a uid search (manually, via an XML query, as python-caldav does some additional magic).
    On a test OX App Suite, with a test user that has two events, I'm getting the two events back when querying for one:
    • Events stored in the DB for that user:
      select uid from calendar_event WHERE user = 14 limit 10;
      	| uid |
      	| 02f634a9-36d4-4872-934a-cb9e39882b17 |
      	| 9010807e-fe0f-4939-b9ca-bef8a1a6238e |
    • Script output:
      python --no-ssl-verify https://<server>/dav/caldav/ <testuser> <password> 9010807e-fe0f-4939-b9ca-bef8a1a6238e 2>/dev/null
      	Found UID: 02f634a9-36d4-4872-934a-cb9e39882b17
      	Found UID: 9010807e-fe0f-4939-b9ca-bef8a1a6238e
    Attached Files

  • #2

    I forwarded your question to one of our developers and got some feedback:
    CALDAV:calendar-query only allow filtering by component and timeframe. Searching for property values is not supported and not easy/not planned as of today.


    • #3

      Thanks for the feedback.
      I found two work around, so I can live with that answer:
      • Filter the output (like what python caldav does)
      • Access the resource by its HREF directly instead of searching the UID...
      Maybe to make it clear the CalDAV implementation could send an error back if one tries to do any property/text matches instead of ignoring that part of the filter?
      Note however that, from what I understand from RFC4791 (in particular section-7.5), this feature might be required (MUST) for CalDAV servers, so clients might assume it's there and break (more visibly than before) if such an error is sent back...

      In any case, thanks for supporting CalDAV in the first place