CalDAV REPORT queries return empty results for shared calendars accessed by non-owner users via ACL

[jarimustonen]

Issue Description

When sharing a CalDAV calendar with another user via WebDAV ACL, the non-owner user can discover the calendar (PROPFIND works), but calendar-query and sync-collection REPORT queries return zero events. The calendar owner sees all events correctly with the same queries.

Environment: Stalwart v0.15.5, PostgreSQL 17, behind nginx reverse proxy, Ubuntu 24.04 LTS.

Expected Behavior

A user granted read/write ACL privileges on another user's calendar should be able to query events via calendar-query and sync-collection REPORT, returning the same events the owner sees.

Actual Behavior

• PROPFIND on the shared calendar works — returns displayname, resourcetype, ctag, etc.
• calendar-query REPORT returns an empty <D:multistatus> with zero <D:response> elements
• sync-collection REPORT also returns no member URIs

The calendar owner's queries return all events correctly. Only cross-user access is broken.

Reproduction Steps

1. Create two users: alice and bob, each with a default calendar
2. Add events to alice's calendar
3. Grant bob read/write access via ACL:

curl -X ACL 'https://server/dav/cal/alice/default/' \
  -u 'alice:PASS' \
  -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<D:acl xmlns:D="DAV:">
  <D:ace>
    <D:principal><D:href>/dav/pal/bob/</D:href></D:principal>
    <D:grant>
      <D:privilege><D:read/></D:privilege>
      <D:privilege><D:write/></D:privilege>
      <D:privilege><D:read-current-user-privilege-set/></D:privilege>
      <D:privilege><D:bind/></D:privilege>
      <D:privilege><D:unbind/></D:privilege>
    </D:grant>
  </D:ace>
</D:acl>'

4. Verify PROPFIND works as bob (returns calendar properties):

curl -X PROPFIND 'https://server/dav/cal/alice/default/' \
  -u 'bob:PASS' -H 'Depth: 0' -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0"?><propfind xmlns="DAV:"><prop><displayname/></prop></propfind>'
# Returns: HTTP 207, displayname visible — works

5. Run calendar-query REPORT as bob:

curl -X REPORT 'https://server/dav/cal/alice/default/' \
  -u 'bob:PASS' \
  -H 'Content-Type: text/xml' -H 'Depth: 1' \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:prop><D:getetag/></D:prop>
  <C:filter><C:comp-filter name="VCALENDAR">
    <C:comp-filter name="VEVENT"/>
  </C:comp-filter></C:filter>
</C:calendar-query>'
# Returns: empty multistatus — 0 events

6. Run the same calendar-query as alice (owner):

curl -X REPORT 'https://server/dav/cal/alice/default/' \
  -u 'alice:PASS' \
  -H 'Content-Type: text/xml' -H 'Depth: 1' \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:prop><D:getetag/></D:prop>
  <C:filter><C:comp-filter name="VCALENDAR">
    <C:comp-filter name="VEVENT"/>
  </C:comp-filter></C:filter>
</C:calendar-query>'
# Returns: all events — works

Relevant Log Output

No response

Stalwart Version

v0.15.x

Installation Method

Binary (Linux)

Database Backend

PostgreSQL

Blob Storage

PostgreSQL

Search Engine

Internal

Directory Backend

Internal

Additional Context

No response

I acknowledge that:

• I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
• I have searched the Stalwart repository (both open and closed Discussions and Issues) and confirm this is not a duplicate.
• I have set the logging level to trace and included relevant log output if applicable.
• I agree to follow the project's Code of Conduct.

[mdecimus]

Thanks for the report, I'll investigate and post an update here soon. There is a similar report at #2651

[jarimustonen]

I forgot to mention in this and the second issue that I posted (#2854) that I'm using Fantastical on MacOS.

[jarimustonen]

I have now reported this to Flexbits, the company behind Fantastical. I hope they will comment this here.

[jarimustonen]

They wrote back to be the following:

Our team is looking into this now, and we believe we might have a fix coming that will help in our next update.

[jarimustonen]

This was a confirmed but in Fantastical and has been fixed in version 4.1.10. Huge thanks to @mdecimus for giving proper diagnose to this issue.

[mdecimus]

Great!