Shared calendars not appearing in CalDAV discovery response #3074
Replies: 5 comments 4 replies
|
Have you shared them? Which client are you using? Logs? |
|
Hi, took a closer look at this together with #3135 since the symptoms are very similar. I set up a fresh v0.16 instance with two test accounts and shared a calendar between them via every code path I could think of: JMAP So the sharing logic itself is fine on a clean v0.16 install; whatever you are hitting is state-dependent. One concrete cause that produces exactly this symptom: in v0.16, account names must be full email addresses, while v0.15.x accepted plain local-parts as well. The URL parser in v0.16 only resolves account segments of the form Could you try removing the calendar account from your client and adding it back from scratch? That forces a fresh discovery against the new URL format. If your accounts were originally created on v0.15.x with non-email names, you may also need to rename them on the server to If re-adding the client account doesn't help, please raise the log level to |
|
This is my very first time using stalwart and I started with version 0.16. Always used the full email as usernames. Happens with betterbird and davx5. I don't see shard calendars when the caldav client queries https://mail.mydomain.com. I see my own calendars fine. I can even manually add the URL to the shared calendar and that works so I don't think it's an acl problem. I'll get some trace logs tonight. Just checked in the sharing calendar section in stalwart and something is off. It's showing the letter C for my user account that this calendar is shared to. I believe that is the id of the user. Maybe this is part of my problem? Something is corrupted.
|
|
It's happening with all caldav clients I have tried. /dav/cal doesn't list shared calendars even with assisted discovery enabled . Here's some curl tests and some trace logs. |
|
Figured out the issue. Took a while and I almost wiped and reinstalled stalwart. Sharing a calendar user to user works fine and they appear in the users /dav/cal list. When a user is an ADMIN that PROPFIND doesn't return any shared calendars. All I had to do was make my account a regular user account and now it works as it should. |

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Issue Description
PROPFIND on /dav/pal/ correctly returns both principals including shared ones, but PROPFIND on /dav/cal/ only returns the authenticated user's own calendars; shared calendars are missing from the calendar discovery response
Expected Behavior
/dav/cal returns shared calendars
Actual Behavior
No response
Reproduction Steps
No response
Relevant Log Output
No response
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
PROPFIND on /dav/pal/ correctly returns both principals:
curl -u user@example.com -X PROPFIND https://mail.example.com/dav/pal/ -H "Depth: 1"
Returns both user@example.com and shareduser@example.com.
PROPFIND on /dav/cal/ only returns the authenticated user's own calendars:
curl -u user@example.com -X PROPFIND https://mail.example.com/dav/cal/ -H "Depth: 1"
Only returns /dav/cal/user%40example.com/. The shared calendar at /dav/cal/shareduser%40example.com/ is not in the response.
Directly accessing the shared calendar URL works fine though:
curl -u user@example.com -X PROPFIND https://mail.example.com/dav/cal/shareduser%40example.com/ -H "Depth: 1"
Returns 200 with the correct data. So the permissions are working at the resource level, the discovery just doesn't include shared calendars from other principals.
I acknowledge that:
traceand included relevant log output if applicable.All reactions